4 ms·

I might be somewhat biased on this, but I strongly prefer database metaphor over computing metaphor. Every blockchain is essentially a shared database. E.g. Bi

I might be somewhat biased on this, but I strongly prefer database metaphor over computing metaphor. Every blockchain is essentially a shared database. E.g. Bitcoin is a database which keeps track of address balances (as a first approximation) and enforces particular authorization rules. It's a fixed-functionality blockchain. On the other hand, Ethereum can serve as an arbitrary, user-defined database. Ethereum smart contracts are essentially like stored procedures in SQL databases -- they can be used to enforce arbitrary consistency rules. And the reason why transactions are quite expensive is that you're paying to update everyone's database. You can modify things locally for free, but if you need everyone to see your information, you gotta pay for it. And computation is there just for the sake of enforcing arbitrary constraints.

kochthesecond 9y ago
I also prefer the database metaphor. Bitcoin is a set of rules that lets everyone take part in (in fact this is required) the creation of a database of transactions that has happened. To make sure there are no mistakes, every single node runs the transactions to verify their validity.
mettamage 9y ago
I just wanted to thank you because while I viewed it this way I've never seen it so eloquently in words. My way of putting it into words was still a bit chaotic, so thank you!
infogulch 9y ago
Interesting. Can I ask for a description of the Etherium database from the perspective of someone shopping databases? Paradigms, features, transactions, distributed consensus, etc.
- killerstorm 9y ago
  On a low level it consists of multiple key-value stores (one store per contract). Keys and values are 256-bit integers (or 32-byte byte strings). You never work with it directly, instead, you deploy a contract, which is sort of a collection of stored procedures. On the low level contracts are executed as imperative bytecode with special opcodes for reading/writing data to KV store. There are also high-level languages which compile to this bytecode. Particularly, Solidity lets you to develop contracts using object-oriented metaphor: contract is an object, its store is accessible via object's fields. Besides primitive types, it supports types like structs, arrays and associative arrays, which can be nested. Compiler takes care of mapping field access to raw key-value store operations, particularly, it relies on cryptographic hash functions for layout mapping instead of deterministic allocation. Contracts can also call each other, there is an opcode for it. Calls are done synchronously, so it looks exactly like OOP. Since this database exists in multi-user environment, access control is necessary. The system identifies users using cryptographic signatures and exposes this information to contracts via `msg.sender` field. Contracts can use it to implement custom authorization policies. The database is transactional, of course: a user-submitted transaction is either executed in its entirety (incl. all nested calls) or fails with all side-effects reversed). Transactions are executed serially, one at time. So high performance is not a feature of the system, it is more like "high security". Reading data can be done via "stored procedures" (well, I think technically you can read raw data from key-value store, if you want to). Also there is a separate "event log" mechanisms: contracts can generate custom event logs, which can be later read externally. Distributed consensus: Each node has a complete copy of the database, so adding more nodes doesn't increase scalability. Currently Ethereum uses proof-of-work consensus. That means that any (mining) node can propose a new block of transactions to be executed, and eventually they converge to a single chain. So it's stochastic. There are also "private Ethereum" systems which let you to use different consensus mechanisms. Typically they have Byzantine Fault Tolerant consensus, likely inspired by PBFT. It's kinda like Paxos but with more digital signatures.

kochthesecond 9y ago

I also prefer the database metaphor. Bitcoin is a set of rules that lets everyone take part in (in fact this is required) the creation of a database of transactions that has happened. To make sure there are no mistakes, every single node runs the transactions to verify their validity.

mettamage 9y ago

I just wanted to thank you because while I viewed it this way I've never seen it so eloquently in words. My way of putting it into words was still a bit chaotic, so thank you!

infogulch 9y ago

Interesting. Can I ask for a description of the Etherium database from the perspective of someone shopping databases? Paradigms, features, transactions, distributed consensus, etc.

killerstorm 9y ago
On a low level it consists of multiple key-value stores (one store per contract). Keys and values are 256-bit integers (or 32-byte byte strings). You never work with it directly, instead, you deploy a contract, which is sort of a collection of stored procedures. On the low level contracts are executed as imperative bytecode with special opcodes for reading/writing data to KV store. There are also high-level languages which compile to this bytecode. Particularly, Solidity lets you to develop contracts using object-oriented metaphor: contract is an object, its store is accessible via object's fields. Besides primitive types, it supports types like structs, arrays and associative arrays, which can be nested. Compiler takes care of mapping field access to raw key-value store operations, particularly, it relies on cryptographic hash functions for layout mapping instead of deterministic allocation. Contracts can also call each other, there is an opcode for it. Calls are done synchronously, so it looks exactly like OOP. Since this database exists in multi-user environment, access control is necessary. The system identifies users using cryptographic signatures and exposes this information to contracts via `msg.sender` field. Contracts can use it to implement custom authorization policies. The database is transactional, of course: a user-submitted transaction is either executed in its entirety (incl. all nested calls) or fails with all side-effects reversed). Transactions are executed serially, one at time. So high performance is not a feature of the system, it is more like "high security". Reading data can be done via "stored procedures" (well, I think technically you can read raw data from key-value store, if you want to). Also there is a separate "event log" mechanisms: contracts can generate custom event logs, which can be later read externally. Distributed consensus: Each node has a complete copy of the database, so adding more nodes doesn't increase scalability. Currently Ethereum uses proof-of-work consensus. That means that any (mining) node can propose a new block of transactions to be executed, and eventually they converge to a single chain. So it's stochastic. There are also "private Ethereum" systems which let you to use different consensus mechanisms. Typically they have Byzantine Fault Tolerant consensus, likely inspired by PBFT. It's kinda like Paxos but with more digital signatures.