Earlier quoted context omitted.
Blockchain has a lot of distinct advantages when things need a very clear audit trail. Auditors love the fact that a block can't be modified without recalculating all subsequent blocks. Of course, in a blockchain controlled by a single private entity, the entity could redo all the blocks, but that's not really the main concern. The concern is to try to prevent rogue individuals from modifying the ledger without detec…
Blimey! Here I thought any database server worth a rusty copper can do a detailed, queryable audit log / trail if that's what you need. At least MySQL, PostgreSQL, SQL Server, DB2, Oracle surely can.
What Is Ethereum?
271–272 of 272 posts
Re: What Is Ethereum?
#272Earlier quoted context omitted.
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…
Interesting. Can I ask for a description of the Etherium database from the perspective of someone shopping databases? Paradigms, features, transactions, distributed consensus, etc.
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.