gochain / gips Goto Github PK

Aside from solving performance issues, GoChain also has a goal of fixing another huge problem with Ethereum and that is theft prevention. Theft on Ethereum is almost always related to bugs in smart contract code (besides gaining someone’s private key via social engineering, SMS hijacking, etc). $100’s of millions (if not billions) have been stolen in the past couple of years due to bugs in smart contracts.

One way to reduce the chance of theft by bugs is the ability to pause a contract (stop the theft) and upgrade it (fix the bug that makes the theft possible). This proposal is to enable both of those features. A nice side effect of this is that contracts can be upgraded for other reasons too, such as adding new functionality to a DApp or amending a contract which reflects real-life contracts.

Pausing a contract

The first step would typically be to pause a contract to stop someone from taking advantage of a known bug. Since this one doesn't change the contract or the data, the owner could pause a contract without the knowledge of other involved parties and this would not break trust. Also, this has to be able to happen immediately so letting a single entity be able to do this is a must.

Who can upgrade a contract?

One of the main selling points about smart contracts is that they are immutable and therefore you create a level of trust between different parties that may otherwise not trust each other. If one party can change the contract, you lose the trust. So how can we continue to have trust between parties while still allowing a contract to be upgraded? Upgrading the contract itself isn't the hard part, having a system that retains trust while allowing upgrades is the hard part.

The default upgradeability will remain the same as it is now, which means nobody can upgrade it. To enable an upgradeable contract, it must be set during the deployment of the contract.

The owner (the deployer) would set upgradeability rules on the contract during deployment which defines how a contract could be upgraded. Some example rules:

• owner only (single voter)
• Vote
  • The upgrader would deploy the new contract then a vote would start
  • a) by %: X% of all parties that use contract must vote “yes” for the contract to take effect
    • NOTE: This might get out of hand if there’s too many users of the contract
  • b) by specific addresses: The addresses in the list must vote “yes” for the contract to take effect

These rules would be visible to all, so a user can decide whether to interact with the contract or not. If they know the upgrade rules, they can make an informed decision.

How it would work technically

Interacting with a smart contract requires the contract address. The contract state is also stored in the Merkle Patricia Trie under that same address. One requirement is that the address stays the same so people can continue to use the same address after the upgrade.

The owner would call upgradeContract() function with the same parameters as deploying a contract plus the previous address to override.

In order to use the same address with new code, we could do one of the following (after it's been voted in):

1. Make a new account, copy the state, then make an alias/pointer from the old account to the new one. Any incoming calls to the original contract address will be redirected to the new contract address. Downside of this is that it would double the storage space used and the old state would sit there forever. Would have to have some way to clean up old state after some time.
2. Store the new code then change the codeHash for the existing account. This would use the same storageRoot with new code. Downside of this is that we might lose some context? Probably need to store a previousCodeHash too or something along those lines).

Once deployed, the contract becomes active again (unpaused).

Open Questions

• What if a data migration is needed?
• Can the owner be changed?
• Can upgradeability be upgraded? i.e. Can 'owner-only' be upgraded to the other voting modes?

In Ethereum, ether calls are not compatible with ERC20 standard because ERC20 was conceived much later. Thus, ether cannot respond directly to ERC20 calls.

Advantages

1. Ether responding to ERC20 calls would greatly simplify the codebase of applications like Decentralized Exchanges.
2. Fast user experience due to no wrapping of "GO" into GO20 compatible token "Wrapped GO".

A healthy discussion can be found on this reddit thread.
Starting from "cryptopascal" comment!
https://www.reddit.com/r/ethereum/comments/6zfihg/ethereums_erc20_token_standard_has_been/#t1_dmwah0s

What can be the approach:

1. Changing codebase of core blockchain to make GO support GO20 standards.
2. Having an GO20 compatible abstract contract which calls ether transfer methods underlying GO20 methods, without any need of wrapping GO.

Simple Summary

Increase minimum gas price.

Overview

This is a proposal to increase the minimum gas price that nodes will accept by 1000x.

Motivation

UPDATE: GO price has gone up since this was created, so be sure to adjust for current price.

Gas on the GoChain network is extremely low. The following are the current transactions costs, USD equivalent based on $0.01 per GO:

• A normal GO transfer transaction costs 0.000042 GO ($0.00000042)
• An GO20 transfer transaction costs ~0.0001 GO ($0.000001)
• A complex transaction (a uniswap swap transaction) costs ~0.00025 GO ($0.0000025)
• 1 GO (or 1 cent) is all it costs for 23,809 transactions

The problems with the cost being too low:

• Even at full capacity of 1300 transactions per second, the fees will not generate enough to even cover the bare minimum cost of running the network.
• It would be very cheap for someone to saturate the network and degrade service for everyone else. $0.036 per day is all it would cost to submit 1300 transactions per second.
• The extremely low cost of a transaction, means the value of GO is also very low
• Without more fees, the cost of running the network relies on block rewards which means there will always need to be inflation
• Enterprise partners understand that they should pay a reasonable amount for their infrastructure. The current price is so low that it is nearly free for enterprises. Fees can be increased 100-1,000x without exceeding the threshold of what a reasonable fee is for enterprises.

Fees collected at current price at 10 transactions per second: $25.92 per month

At 1000x the price:

• A normal GO transfer transaction would cost 0.042 GO ($0.00042)
• A GO20 transfer transaction would cost ~0.1 GO ($0.001)
• A complex transaction (a uniswap swap transaction) would cost ~0.25 GO ($0.0025)
• Fees paid at 10 tps: $25,920

Increasing the gas would increase the value of the entire network, set a fair price for using the network (it shouldn’t be free), reduce the chance of network saturation and can lead to being able to reduce block or remove block rewards (see GIP-30).

Specification

Nodes would reject transactions below 2000 gwei. Currently 2 gwei.

eth_gasPrice would return a minimum of 2000 gwei.

WebAssembly has become a browser standard and is gaining steam as the new way to develop for the web. https://webassembly.org/ While it was intended for browsers, it's properties are actually very nice for blockchain development too.

• Small binary format
• Near native speed (better then EVM)
• Multi-language support

Having this on GoChain would enable a whole new realm of developers that don't know Solidity and would not have to learn solidity to write smart contracts.

Burn all gas used for transaction fees.

Overview

Burn all transaction fees in order to reduce inflation.

Motivation

Burning gas would reduce GO inflation and potentially even cause deflation after enough volume is reached.

Prereq: #29 increase fees

The primary goal is to eliminate inflation. By burning gas, we offset the block rewards and at a certain amount of transactions it will be deflationary. At less than 14 tps, rewards will be eliminated depending on the contract gas requirements. Anything over 14 will be deflationary meaning GO’s total supply will decrease.

Specification

All gas fees collected in a block are not taken by the node signing the block, and therefore effectively burned.

Additional Information

Q: how to publicly track burnt gas so we can calculate total supply?

Would it be possible to introduce a Function for Batch Transfer via a method call to allow 254 times more TPS?

The function would be similar

With a form of automated method calls

Similar to something like;

Function multiPartyTransferFrom(address _from, address[] _toAddresses, uint256[] _amounts) public {
/* Ensures _toAddresses array is less than or equal to 255 /
require(_toAddresses.length <= 255);
/ Ensures _toAddress and _amounts have the same number of entries. */
require(_toAddresses.length == _amounts.length);

    for (uint8 i = 0; i < _toAddresses.length; i++) {
        transferFrom(_from, _toAddresses[i], _amounts[i]);
    }

This would allow a low cost, energy effiency way of transferring more TPS. The Method Call would automatically go into place as orders are being sent across the Blockchain network. It’s something similar to the BTC blockchain.

_{Sent with GitHawk}

Bring Full Staking to GoChain Network

Summary

There is little benefit to hold Go due to very stable price action and no staking rewards. Future price increases are the only ways for holders to benefit from holding Go. There is little benefit to hold Go in the present short of speculation.

Why

Bringing full staking to Go would reward holders for investing in the project and create immediate incentive for new users to invest. Allowing staking on the network would instantly create new demand for Go as users will want to take part in the staking rewards. This new demand will also drive the value of Go upwards. Allowing a percentage of the total supply of GoChain to be staked instantly reduces the circulating supply, creating deflation, further increasing the price of Go. Additionally, as users obtain Go to partake in the staking, more network activity will be created, exposing the crypto community to the speed and affordability of the GoChain network, thus bringing further attention to the project. Further, the rewards will create more volatility and thus price action as a certain number of users will sell their rewards on exchanges, increasing trading volume, volatility, price action, while bringing further attention to the project. Staking also moves GoChain towards being more decentralized as investors are rewarded for investing in the project and giving more users the power to vote on new governance proposals (such as this one).

Specification

Each new block generates 7 new GO which are currently paid to validators. The reward to validators would be cut in half to 3.5 Go. The other half would be used for staking.

Staking rewards would be paid out weekly based on the percentage each wallet contributes to the pool. This would be ~423,360 (86400 / 5 sec per block * 3.5 GO per block * 7 days) GO paid out each week or 22,014,720 per year.

As an example, if 110M GO were staked (~10% of total supply), APY would be ~20%.

Rules:

• Staking period: 7 day intervals (yes this is short, but allows more activity on the network and volatility in the markets)
• GO would have to be submitted to a staking address (this might be a single address for everyone, or a unique address for each wallet)
• Minimum amount to stake (initially): 25,000 GO
• Users are able to pull out any amount of their GO at any time. The rest will continue to earn rewards.
• Only the amount that remained staked during the entire payout period will be rewarded. Meaning, if you staked 25,000 Go and pull out 10,000 before the end of the payout period, you'll only be rewarded for the 15,000 Go. This is also true for adding to your staked amount.
• Staking rewards are automatically added to a wallet's staked amount

Place your vote by clicking the 👍 here:

Summary

Upbring.org, an organization dedicated to advancing child well-being, wishes to join the GoChain network as a node operator. Upbring aligns with GoChain's core values and the foundation thinks they would be a welcome addition.

The Steering Committee voted unanimously +1, so now it's time for the community to vote.

Voting will go live within the next 24 hours. Please subscribe to this issue to receive notifications.

The driver behind this idea is to encourage adoption of the Gochain network.

Assumptions:
Total Go supply = 1,000,000,000 (1 Billion)
Signer Node Rewards = 4.5% of total supply adjusted per year.
Estimated amount of Go towards nodes per year: = 45000000 (45 Million)

Assuming 50 nodes reached after 12 months: 900,000 GO per node per year.

At a current conservative valuation of 0.05c per GO, the total dollar value that signer nodes are rewarded with = $2.25 million per year.

This suggestion is to break up the 4.5% into a few different components that may encourage network / protocol adoption as follows:

Once a company / enterprise is approved as a signer node, they receive rewards on the following basis:

Only 90% of the 45 million GO to be used for signer nodes: (40,500,000 per year at the current rate)

• Year 1 - 50% of rewards - 50% of reward towards dApp development fund.

• Year 2 - 60% of rewards - 40% of reward towards dApp development fund.

• Year 3 - 70% of rewards - 30% of reward towards dApp development fund.

• Year 4 - 80% of rewards - 20% of reward towards dApp development fund.

• Year 5 - 100% of rewards - 00% of reward towards dApp development fund.

The remaining 10% of the signer node rewards can be used in a number of ways in order to encourage further community adoption / or even some form of CSR.

• Airdrops to existing community members based on current Go allocation.

• Gochain sponsored community events. University Scholarships (Blockchain based).

• Other ideas welcome.

To be discussed:

• How the Gochain dApp fund can be managed in a transparent manner.
• Should VC's be involved / entrusted with the funds.
• Should VC's be engaged with only on the basis that they also contribute 50% towards the dApp start-up that is to develop on Gochain.

In Summary:
The 5 year reward system should encourage signer nodes to act in the interest of the Gochain network at all times and be in the for the long run as rewards increase with time up and until the 5 year limit when 100% of rewards are paid out.

As the Gochain network grows, it is also important to understand how the existing nodes run by Gochain use the rewards accumulated by their own nodes. The community has no doubt that these funds are used towards building out partnerships / enhance the eco-system, but in the order to avoid unnecessary negative scrutiny in the future it would be helpful to have a single rule that fits all signer nodes in this regard.

Open to further discussion / suggestions.

One of the primary longer term goals of GoChain is theft and loss prevention. In blockchain, both are equally as bad to a holder of coins or tokens as either way you lose everything. Upgradeable smart contracts which GoChain will be implementing can help prevent theft, but it doesn’t prevent loss. Loss can come in many forms such as losing your private key or death. If you die and your family is unable to obtain your private key, the funds will be inaccessible and any inheritance is lost. This improvement proposal is focused on the death scenario and being able to pass on your funds to your beneficiaries.

What is it?

This feature would allow a user to set a number of beneficiaries tied to an account (an address) that would allow the beneficiaries to claim the user’s funds upon death.

How it would (could) work

The owner of account A can set the beneficiaries of her account through a signed message to a GoChain API endpoint. The user would set which accounts can claim the funds and what percentage they get. The message also includes an inactivity timeout at which point the beneficiaries could claim the funds. There could be multiple levels of beneficiaries in case the first level is unable to claim the funds (ie: they have passed).

An example of this message might look like this:

In this example, if account A has no activity for the inactivity timeout, 6 months in this example, then the next level of beneficiaries can “claim” the funds for the timeout set for that level. This can continue for many levels (todo: any limit on levels?).

There could be a final account in the tree that the funds would automatically be transferred to after the last timeout in the tree, without requiring a claim.

How it would work technically

• User A calls a setBeneficiaries() function with a json message, containing the beneficiary tree, signed by her private key.
• Inactivity timeouts are defined by the number of blocks or seconds (probably better)
• User must use their wallet at least once before the inactivity timeout, OR if the funds aren’t claimed yet, to reset the timer. A new "touch()" function will be created to reset without needing to perform an action
• A beneficiary can make a claim by calling a claim() function. If the time is currently in the window for this beneficiary, the funds will be transferred to their account.
• If a fallback address is given, the funds will be transferred to that account automatically after the final timeouts have been reached

Notes

• Need to add consensus verification on claims

In an effort to support stablecoins on GoChain, backed by existing stablecoins on Ethereum (USDC, TUSD, PAX, etc), I propose the following cross chain transaction concept, aka GOST Protocol, to be built into GoChain. This concept keeps the transfers decentralized as the protocol is built directly into GoChain and requires all nodes in the network to participate. Tokens can be transferred to GoChain and transferred back to Ethereum at any time. This would make GoChain one of the first (if not the first) truly interoperable blockchains.

Why Move Tokens to GoChain

Much faster transaction speeds, supports much higher transaction volumes and much lower fees that can support day-to-day purchases such as buying coffee or playing games.

Fees

As of right now, the average transaction fee for Ethereum is $0.15:

And the average transaction fee for Bitcoin is $3.66:

Those fees are much too high for day-to-day transactions. You can't use it as payments for coffee if the fee costs just as much as the product.

Speed

Similarly you can't buy coffee if customers have to wait at the cashier for minutes or hours. GoChain transactions are almost always under 5 seconds.

Bitcoin typically takes a minimum of 10 minutes for a single block confirmation since block times are 10 minutes. It's usually longer since the network is typically congested. Ethereum block times are 15 seconds which is a vast improvement over Bitcoin, but the problem is the Ethereum network is also almost always congested so it typically takes minutes for a transaction to make it into a block.

Here is an example of two transactions at the same time performed at a random day/time on GoChain and Ethereum. Ethereum took 3 minutes 29 seconds to make it into a block while the GoChain transaction took 1 second.

Cross Chain Consensus

Consensus so far in blockchains has been limited to agreement on a single blockchain (ie: the database). There is no reason why consensus has to be restricted to a single data set. GOST Protocol works by the GoChain node network coming to consensus on both GoChain data and another chain's data (Ethereum to start). After a certain number of blocks have passed, we can be fairly certain that the data is set in stone and can no longer be modified, much like exchanges accept transactions after a certain number of block confirmations.

Transferring Tokens to GoChain

Each token on GoChain represents exactly one of the same token on the original chain. Let’s use USDC in this example. Transferring to GoChain requires two steps:

• User deposits X USDC to a special smart contract on Ethereum - GOST-C1 (very similar to a multi-sig wallet)
• GoChain nodes monitor this contract for transactions
• If a transaction is found, the nodes will wait X blocks for confirmation (30-60)
• After confirmation, a minting transaction is confirmed. X USDC on GoChain (USDC? GOUSDC? GOUSD?) is minted in an ERC20/GO20 token contract on GoChain to the original depositors address

Transferring Tokens back to Ethereum

User has to burn tokens on GoChain to get the original tokens back. This could work the following way:

• User sends a burn transaction tx3 to burn tokens in in the token contract on GoChain (can include extra data such as a withdrawal address on Ethereum)
• GoChain nodes accept the burn transaction, tx3, immediately removing the tokens from circulation
• After X (30-60) block confirmations, each node sends in a transaction to the GOST-C1 wallet on Ethereum which says to transfer the funds to the address in tx3
• Once a high percent of nodes (75%?) submit their transaction, the transaction proceeds and the tokens are transferred to the user

Future

Beyond this initial use case, this paves the way for massive scalability increases for GoChain by enabling multiple GoChain networks to work together. GoChain -> GoChain transactions means we can create any number of GoChain shards which can then transact across each other.

how about you wont advertise your chain with promise of becoming 10 times more decentralized than ethereum if you are looking to run it in 50 nodes that would run on centralized cloud services like AWS and azure.
instead though you could act honest and advertise that you are scaling ethereum with chain that is run by trusted network and will have interoperability with ethereum. once again you dont even need to code interoperability yourself but it is something parity/polkadot provides to you in silver platter(made to operate with POA):
https://github.com/paritytech/parity-bridge

Placeholder.

Summary

New GoChain node validators onboarded and operating during the period of 15 March 2021 - 15 March 2022 will allocate a minimum of 50% of monthly rewards to the GoChain Foundation for specified R&D work, hackathons, and other innovation-focused work.

Motivation

Provide additional utility and deepen engagement among all GoChain node signers, the Foundation, and community, while reinforcing and further supporting the Proof of Reputation consensus framework. The opportunity for GoChain Foundation and the broader community to support node innovation and Environmental, Social, and Governance (ESG) objectives should not only help to realize additional value for the overall ecosystem & network but also have a positive impact on society and the world.

Mechanics

During the period of 15 March 2021 - 15 March 2022, 50% of any new node signer’s token rewards will be sent to a specific GoChain Foundation wallet address each month. New node signer(s) and the Foundation will agree upon specific blockchain-based work, i.e., research initiatives, POC, hackathons, etc. which will be funded by the token balances.

Additional Information

In addition to the Foundation, community members will have the opportunity to participate, earn tokens and support the research projects. The wallet and all tokens will be publicly accounted for and verified for each initiative. After this 12-month period, all node signers for the GoChain network going forward will be required to allocate a minimum of 50% of monthly rewards to fund similar innovation or ESG-related research initiatives.

Summary

Instead of proving you have X amount of GO to vote with like we've done in the past, voters would vote with GO which would be burned.

Why

Pros

• Voters would really have to believe in what they're voting for as it would cost them
• Can't cheat (once you've voted, the GO is gone and can't be moved around to cheat the system)
• Burns GO and reduces supply
• Simple process

Cons

• Whales would have a clear advantage.... but they already do anyways with the proof based system so 🤷

Specification

• Each vote option would have an address, eg: YES address and NO address for yes/no votes.
• At the cutoff time, the one with the higher balance wins
• After, all tokens in all vote addresses are burnt

Additional Information

You could also potentially have a blind vote so nobody knows what the current tally is. In this case, each voter would choose their answer then get an address to send to. At the cutoff time, all the addresses balances would be summed up then burnt.