Comment by drcode | Hacker News Reader

Comment by drcode | Hacker News Reader

Parent Full thread

Some important properties of ethereum:

1. A program written in ethereum can execute code at a predetermined point in the future, and there is as close to 100% certainty as possible that the code will execute as written (i.e. as long as a single ethereum user remains in the world at that date everybody's code is guaranteed to run exactly as written, even if it involves moving money between accounts.)

2. All computer programs are "open source" not just before a program is launched but also WHILE THE PROGRAM IS RUNNING- Nobody can run any code without having full transparency.

3. Users accounts are provably always in a state of complete anonymity (unless of course they do something to purposely reveal their identity) and can use all programs on the platform in this fully anonymous state.

4. Program authors are forced to explicitly document ahead of time all situations in which their program code might be modified in the future, making it much harder to have the "screw your user after they've committed to your platform" business model that's so popular among startups these days.

Those are just some of the properties of ethereum that come to mind.

>4. Program authors are forced to explicitly document ahead of time all situations in which their program code might be modified in the future

Can you point me to a resource that explains this in more detail? I think I've gotten the gist of how Ethereum works, and have gone through a tutorial of Solidity, but I'm unclear how versioning will work in Ethereum (even though I do have some guesses for how it could be implemented).

How would I deploy a new version of my contract? Would I have to implement a mechanism for basically hot loading new code?

Yeah, that's pretty much it: By default, contracts can't be updated, but you can create a network of multiple contracts to allow some of your code to update. Myself, I think this is "cheating" and destroys the value proposition of ethereum... a better approach (and what I hope to do) is to keep my main contract(s) alive for all eternity and just add new features with "accessory contracts" but it's easy to fail with this if the original contract has problems.

If you want your contract to be updateable, you can have the contract store an address of a contract which is the part you might want to change. Then, to update the contract, you upload the new version of the contract ( or contract component) , and make the address that the first contract stores point to the new one.

Uh...

Users interact directly with contract A.

Contract A stores a address which currently points to contract B, and uses whatever contract it currently points to to accomplish whatever it needs to do for users.

To update the part of Contract A, upload an updated contract C, and send A a message to tell it to change the address it stores to point to contract C instead.

Contract A only changes where the address points if whatever conditions it was designed to use for that are met.

And, of course, you don't have to use this "point to another contract" thing.

That's just if you need part of the contract to be updateable under some conditions, which you might not need.

Reply on news.ycombinator.com