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 wor

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.