5 ms·

This explanation subtly forgets to explain which agent is responsible for executing the contract-programs. Obviously you don't want the contract to be processed

• chriswarbo 11y ago
  As far as I understand, it's a distributed consensus system. Scripts don't perform their effects in the "real world"; instead, they append values to a blockchain. External systems can inspect the most recent values in the blockchain and act accordingly. This is how bank accounts work, conceptually. Many programming courses use bank accounts as examples of race conditions in concurrent systems, eg. User withdraws £10 from ATM User receives £1000 salary Balance --------------------------- -------------------------- ------- ATM looks up balance (£100) Bank looks up balance (£100) £100 ATM subtracts £10 from value (£90) Bank adds £1000 to value (£1100) £100 ATM dispenses £10 note Bank sets balance to value (£1100) £1100 ATM sets balance to value (£90) £90 This race condition has blown away the user's salary! However, this is a terrible example, since it is nothing like the actual operation of a bank account! An account is exactly that: an account (log) of what has happened: Debits Credits ------ ------- ATM withdraws £10 Salary adds £1000 The balance is exactly that: the balance of (difference between) the credits and debits. The balance is derived from the account as needed, taking new entries into account as they get added. Blockchains are a way to keep such accounts, in a consistent way without giving any one entity control over updates. For example, the article's Web site ownership system might keep an account with entries like this: User A transfers example.com to User B User B sets example.com IP to 123.123.123.123 When contracts are executed, they can inspect the latest values on the blockchain and append alterations. For example, if user B sets up a contract to transfer ownership of example.com to user C, one of the pre-conditions is that user B owns the domain. Hence after execution we get: User A transfers example.com to User B User B sets example.com IP to 123.123.123.123 User B transfers example.com to User C Anyone can execute the same contract on their local copy of the blockchain to get the same result, hence everyone can reach a consensus about what the new blockchain should contain. The contract also can't be run twice in a row, because the resulting blockchain says that User C owns the domain, and hence user B doesn't have permission to transfer it. The same thing happens to any currency which B and C might transfer in exchange for the domain. To actually use such a value, we can imagine a DNS-like system which resolves names by looking up the latest IP address from the blockchain; in the same way that an ATM displays our current balance by looking at the credits/debits in the account. All of this can also be cached, of course; provided we either trust the cache to provide the right value, or that we don't care enough about the value to verify it ourselves (eg. transactions between third parties which do not affect us).