137

Once a contract is in the blockchain, it is final and cannot be changed. Certain parameters, of course, can be changed if they are allowed to change via the original code. One method of updating contracts is to use a versioning system. For example, you could have an entryway contract that just forwards all calls to the most recent version of the contract, ...


33

One method is to use a System of Contracts as outlined below: Contract "Register" - will contain pairs "name - address" for all contracts of your system; Contract Backend; Contract Frontend using Backend; Deploy Register & get address of it; Deploy Backend & register address of Backend into already deployed Register; Hardcode the address of Register ...


29

Contract code is immutable, the storage is mutable, but you cannot execute code placed into storage, at least for now. Bugfixes to contracts As for bugfixes, the common pattern is to have proxy or lookup contracts to be a gateway to the real one, which in case of a change or bugfix would be replaced. Replacing it also means losing the old storage contents. ...


21

Contracts deployed on a blockchain are immutable, so this means: address and code of a deployed contract cannot be changed deploying a newer (or even identical) contract will create a new address code cannot be added to a deployed contract If the contract issues want to have a way to upgrade the contract code, so that account data and other things carry ...


16

The most voted answer is to use delegatecall and it is very tricky to get correct. https://blog.trailofbits.com/2018/09/05/contract-upgrade-anti-patterns describes some upgrade methods, as well as critical considerations so that you don't introduce more bugs or a buggy upgrade method that doesn't work. Proxy pattern recommendations Check for the ...


12

@Nick Johnson has a base contract for upgradeable contracts. As he says, before using one should be "fully understanding the limitations and drawbacks." /** * Base contract that all upgradeable contracts should use. * * Contracts implementing this interface are all called using delegatecall from * a dispatcher. As a result, the _sizes and _dest ...


8

Yes. There are a number of approaches using which you can upgrade a Contract1 to Contract2, keeping its state(data & balance) with the same address as before. How does this work? A way is to use a proxy contract with a fallback function where each method call/trx is delegated to the implementation contract (which contains all the logic). A delegate ...


7

You're correct. Factories contain the bytecode of the contracts they deploy. It doesn't mean you're not using factories correctly, but it does mean you need to break the accumulation of bytecode in A (a.k.a. MegaFactory). Libraries might be appropriate, but you can also build a MegaFactory factory without blowing the gas budget. Just structure it slightly ...


7

Coming to one of the basic principles at Ethereum that is a Smart Contract cannot be modified after deployment. BUT, you can still have Upgradable Smart Contracts if you put the following into consideration This has to be planed from the start. The key point is number 4. But all the others are essential to have a real and smooth Smart Contract Upgrade. ...


6

Obviously I shouldn't get any money though until someone gets their pizza however I'm not sure the best way to handle the escrow. A general pattern for escrow is that the buyer would send funds to the escrow smart contract. As part of sending the funds, the seller's address is specified in the transaction (as well as data like Pizza ID). When the contract ...


6

According to here: Note it gave us the new contract address. Where did this address come from? It is the sha3 hash of the RLP encoding of the list [address of sender, sequence number of sender]. If you know in advance at what tx nonce you will deploy Allower and you can make this RLP calculation yourself, then you can calculate the address to pass to ...


6

For example with web3js you would have to guestimate if the full consumtion of gas means that a throw happend or you ran out of gas Guesstimation is unnecessary, you can get the estimated gas cost with: let contract_instance = web3.eth.contract(abi).at(address); web3.eth.estimateGas( { from: web3.eth.defaultAccount, to: contract.address, data: ...


5

While individuals may choose to make their Ethereum node publicly available, in most cases this is not necessary nor encouraged. The two main reasons for this are: As a client, you cannot necessarily trust a "random public node" to be honest. There is nothing preventing someone from implementing an API that appears to be a valid JSON-RPC Ethereum node, but ...


5

We(I and My team) have recently worked on Upgradable Contracts problem after referring to colony.io's post on Upgradable Contracts. So, we came with a solution in which we have different layers of contract rather than having one single Contract. If I describe it briefly then one need to make the storage part very generic so that once you create it, you can ...


5

I'll start with the disclaimer that I know next to nothing about Ethereum, and that the first I heard of 4-byte signatures was when I clicked this question in the Hot Network Questions sidebar. That said, according to https://www.4byte.directory/: These 4-byte signatures are defined as the first four bytes of the Keccak hash (SHA3) of the canonical ...


5

Change your error statement to this : bstr[k--] = byte(uint8(48 + i % 10)); It will work because of same bit length of both types.


4

You need to put in consideration the following: This has to be planed from the start. You will need to design your smart contract taking in consideration the following 5 points: You have to have a good testing strategies and tactics. Because the cost of updating the your smart contract can really ruin your life. Keep your smart contracts modular and fairly ...


4

Complementary answer to the Factory usage. Doing some testing on the size of the compiled code, I found out that the compiler only include the code of the created contract if the new operator is called on the contract. If we consider the 3 contracts below with enough content to compare: contract Child { uint i1; uint i2; uint i3; uint i4; ...


4

In general, 0 value transactions pose no threat. However, in practice, it is logical to not accept transactions that do not include any value, especially in transactions whose whole purpose is to transfer value. Many implementations of requiring a value that is greater than 0 do so because of the uniqueness of 0 versus all other numbers. For example, ...


3

Throwing an exception makes it easier to reason about the resulting state on error. It's too easy to accidentally not revert all changes that were made on error if you return a value. Future versions of the EVM will allow a throw construct which lets you read a value out even if state is reverted, and doesn't drain gas for the sub-call.


3

Allows you to have a contract with a stable address, but fully controllable and upgradeable behavior. https://github.com/u2/ether-router https://github.com/ConsenSys/smart-contract-best-practices#upgrading-broken-contracts


3

zos introduced a framework for us to easily implement an upgradable smart contract PTAL: https://docs.zeppelinos.org/docs/start.html


3

There are two different issues that we need to separate: User confusion due to accidental hash collision is indeed something that we worry about, although it should be rare and improbable. If the user tries to do an action whose signature is the same as some other, then it means that the app will either not be able to decode their data on the confirmation ...


3

If you want to avoid having a backend/bd to store data and solely want to run your application on a decentralized way, then a Factory patter should be what you're looking for. This way you can store your campaigns in your factory. I would also recommend you look at the proxy contract patterns. You should create a proxy contract to that point to your factory....


2

We could also fall back on a VARIANT type solution (yes, I don't like it either). Have a mapping (uint => StorageItem). The uint is a field ID. The StorageItem contract would have a string value and an integer type. The type would allow you convert from the string to the needed end type. One weakness here is that at some point, solidity will support new ...


2

I am not sure to what extent it would fix the problem, but one can consider putting the "1-1 relationship" to a separate contract, deployed prior to both Allower and Allowed. contract Handcuffs { address left; address right; // set() must be called by both handcuffed contracts function set() { if (left == 0x0) left = ...


2

So, it's not that hard to create a collision. For the fun of it, I tried a while back to find something which has the signature 0x00000000. Here it is: overdiffusingness(bytes,uint256,uint256,uint256,uint256). However, the chances of a conflict which Has the same signature Has the same length for data Has ABI-encoding which 'fit' both ... Are quite slim. ...


2

Imho yes, they should. Accidental collisions are probably unlikely, but we wouldn't want UIs to go belly up. Malicious collisions however would be a whole different story, and it would be nice to detect these. A future direction might be to pick the correct "collision" based on the contract's bytecode. But that's a whole new can of worms. Bu this is my 2c.


2

Since it's very hard to write correct smart contract code, and the consequences of writing incorrect smart contract code can be very bad, you generally want to optimize for the simplest source code, and the simplest code execution path. require() is shorter and clearer than an if... return flow, and also reduces the amount that the caller has to get right, ...


2

This is similar to the idea of sharing the whitelist in TokenA, but that seems lopsided to me. I would take the modularization to its conclusion and make similarly structured token contracts that share a dedicated whitelist contract. The WL contract would be free of other concerns. Deploy contract WL, then contract TokenA, contract TokenB, etc. contract ...


Only top voted, non community-wiki answers of a minimum length are eligible