Updating Smart Contract in Quorum with no change to the smart contract address
Updating Smart Contract in Quorum with no change to the smart contract address
Loading saved threads...
Nathan Aw · External communityPost link
External question — Ethereum Stack Exchange
Author: Nathan Aw
Original post: https://ethereum.stackexchange.com/questions/53299
License: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/
Adaptation: HTML converted to plain text; contact email addresses removed.
Understand that a smart contract address is deterministically computed from the address of its creator and how many transactions the creator has sent and thus every new smart contract deployment will generate a new address -- this makes a great deal of sense for public ethereum.
In Quorum, if I need to make an update to a smart contract (e.g., add/modify a new trading rule/logic) which has already been deployed, is there some way to ensure that the DApps connecting to the old smart address can swing over to the new smart contract seamlessly? i.e., no downtime needed to rewire the DApp to the new smart contract address.
Say, if downtime is not permitted (critical production system), transactions will continue to be sent to the old smart contract address, is there some way to migrate all the delta transactions sent during this period?
Nathan Aw (Singapore)
Quote
Report
Kaki Master Of Time · External communityPost link
External answer — Ethereum Stack Exchange
Author: Kaki Master Of Time
Original post: https://ethereum.stackexchange.com/a/53300
License: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/
Adaptation: HTML converted to plain text; contact email addresses removed.
No. Not in a pre-implemented way.
sending transactions or reading from the EVM is an operation made to a specific address. Creating a new Smart contract would result in a new blank storage for that contract and sending all the data from a smart contract to an other is not implemented by default in the ethereum client.
So migrating from a smart contract to an other will expose two problems :
Changing old addresses to newer ones in hosted Dapps.
Migrating data from old contract storage to the newer one.
The first problem, can be done manually or preemptively by creating an off-chain DNS like naming system for addresses ( or subscribing to an existing one, it should be there already ).
The second problem, can only be solved by preemptively creating methods that will allow you to extract all data from a smart contract for cases like this, if you didn't then it will be hard.
All of this is applicable to
ethereum
and
quorum
too.
Quote
Report
Nico Vergauwen · External communityPost link
External answer — Ethereum Stack Exchange
Author: Nico Vergauwen
Original post: https://ethereum.stackexchange.com/a/53319
License: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/
Adaptation: HTML converted to plain text; contact email addresses removed.
Not natively..
However there is a simple solution called proxy libraries.
You write a contract registry that ties a bytes32 identifier to a contract address
You write a library that contains your logic.
You write an interface to the library.
You create a proxy and link the interface to it.
You write a storage contract that contains the storage and delegates calls to the proxy.
This way when you want to update your logic you will simply have to deploy a new version of the library and set it's deployed address in the contract registry.
example:
https://github.com/designisdead/blockchain-programmable-incentives/tree/master/contracts
I'm pretty sure that we have the best solution for upgradeable contracts here in our project.
Quote
Report
Post Reply
Quoted from Forex.com.bd-Editorial External answer — Ethereum Stack Exchange Author: Kaki Master Of Time Source score (net votes, not local likes): 0 Original post: https://ethereum.stackexchange.com/a/53300 License: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/ Adaptation: HTML converted to plain text; contact email addresses removed. No. Not in a pre-implemented way. sending transactions or reading from the EVM is an operation made to a specific address. Creating a new Smart contract would result in a new blank storage for that contract and sending all the data from a smart contract to an other is not implemented by default in the ethereum client. So migrating from a smart contract to an other will expose two problems : Changing old addresses to newer ones in hosted Dapps. Migrating data from old contract storage to the newer one. The first problem, can be done manually or preemptively by creating an off-chain DNS like naming system for addresses ( or subscribing to an existing one, it should be there already ). The second problem, can only be solved by preemptively creating methods that will allow you to extract all data from a smart contract for cases like this, if you didn't then it will be hard. All of this is applicable to ethereum and quorum too.
Checking account access…