Podcast #128: We chat with Kent C Dodds about why he loves React and discuss what life was like in the dark days before Git. Listen now.
97

Here's my interpretation, based on the yellow paper: ...the Tries should look more like this:


60

Lets first start with my adaptation of this figure illustrating the Bitcoin block structure: So far so good. All fairly basic. Enter Ethereum and things get a wee bit more complex. After reading through this and this, and as per @eth 's recommendation this, my best interpretation is the figure below: The header field definitions are available in section 4....


27

Conceptually, there are 2 important components of an account-based blockchain: transactions represent state transition functions the result of these functions can be stored A "full/archival" node might store all transactions and resulting state transitions for all block heights in a local data store. This would include all historical states, even those no ...


19

The state has the information of all accounts in the blockchain, it is not stored in each block. The state is generated processing each block since the genesis block. Each block will only modify parts of the state. How to generate the state is defined in the yellow paper (pdf). It is defined in such a way that it can be implemented in any programming ...


14

Ethereum is said to have an account-based blockchain. The state isn't directly stored in each the block. To build a better conceptual understanding, we can say that all account states reside locally on the Ethereum node in the form of “state data”. This is common for performance reasons and is assumed that it will be stored in a Merkle Patricia tree, but ...


13

Technically the states are assembled into a state tree (patricia-tree) linked to the account (balance in case of EAOs and balance and storage in case of contract's account) and to the blocks (figures bellow). Physically the states are part of the blockchain so you could find them in the .ethereum folder (in a leveldb database) of each full node . For more ...


12

Here is a complete structure of a block and where it plays its role in Ethereum's blockchain. You asked for a diagram but i think this would be more explanatory.


10

There is no way to do it via JSON RPC or with web3 API. I've created a repository on Github with an example showing how to read all Patricia trie entries in a block and in any contract storage using nodejs https://github.com/medvedev1088/ethereum-merkle-patricia-trie-example var Trie = require('merkle-patricia-tree'); var rlp = require('rlp'); var levelup =...


9

The description can be found in the Yellow Paper which is the formal specification of the Ethereum protocol. Here are the main pieces of a block: 4.3. The Block. The block in Ethereum is the collection of relevant pieces of information (known as the block header), H, together with information corresponding to the comprised transactions, T, and a set ...


7

No, Solidity code (and EVM code in general) is only able to read the current state at the block at which it is being called. If it were able to read state at previous blocks you would need the entire history of the blockchain to validate a block. By not allowing this, the Ethereum developers made it possible to validate a block with only the current state, ...


6

Here's a picture from V's article regarding data structures for light clients: https://blog.ethereum.org/2014/02/18/ethereum-scalability-and-decentralization-updates/


6

This sounds correct to me. Referring to the graphical interpretation of the descriptions in the Yellow Paper, your 4 tries are shown in the "Information required to derive block header" section. The picture exactly matches your descriptions.


6

The behavior has changed with the release of geth v1.8.0 Fromt the release notes Tracing and pruning: By default, state for the last 128 blocks kept in memory. Most states are garbage collected. If you are running a block explorer or other service relying on transaction tracing without an archive node (--gcmode=archive), you need to trace within this ...


5

Ancient history, but here goes :-) There was one coordinating contract for the initial attack. A later version had a more complex algorithm to generate the empty account addresses, presumably to try to frustrate any future clean-up effort. This one just incrementally worked through the address space. Every time the coordinating contract was called - and it ...


5

Each node keeps a complete copy of the current state, and update it with each new block. New nodes need to reconstruct the state by replaying the state changes in each block, although state-trie pruning allows nodes to not remember parts of the state that they aren't interested in.


4

Fusing nuggets of information from multiple sources (primarily, this and this): State data (together with account balances, contract code and account nonce) is stored by every Ethereum client (or Ethereum node) The Ethereum blockchain includes state roots (one per block) that store the root hash of the hash tree representing the system state at ...


4

Vitalik Buterin gives a compact answer: Every block header in Ethereum contains 3 trees for three kinds of objects: Transactions, Receipts (essentially, pieces of data showing the effect of each transaction), State. You can read a longer version with pictures here.


4

The ethereum state is stored on disk in a merkle tree separate from the actual data of the blockchain (ie. the blocks of transactions). The state is not included in blocks - only the state root is included in the block. The state is immutable, so each time an update is made, the old value is not deleted but persists on disk. Old values can be accessed by ...


4

[Q1] Records in the state trie can exist independently of the state root that references them. Each node is stored in what is essentially a flat hashmap, and nodes have references to allow them to look up their children in the hashmap. In your example, block 175,223's state root has a reference to two child nodes. Block 175,224's state root has a ...


3

I'm going to disagree with the conversation in the comments to the other answer. (Apologies in advance!) I think what's being outlined in the question is generally correct, at least from the way I'd understood things. Are the transaction root hash present in a block pointing to individual tree roots or again its a single tree like state tree (i.e. it ...


3

When you send a zero value transaction to an account that does not exist. The same works for zero value creates (both through transactions and the CREATE opcode) as well as CALLing in to an account that does not exist. This is a mistake, a flaw in the protocol. One we want to fix in the next upcoming hardfork.


3

The state trie contains the balance of each account. Even transactions that throw an exception result in a reduction in the sender's balance through gas costs, which means that the resulting state is different from the initial state. An interesting question would be to see if a transaction with a gas price of 0 can be excluded from a block without changing ...


3

Doing this using web3 over RPC will take forever, as you've found. Reading the .ldb files is the way to go, and is something that's come up in similar questions before. I don't know of any working, up-to-date, .ldb parser, though there must be some in existence, so I'll defer to other more knowledgeable answers you might get. In the meantime... See: LDB ...


3

Interesting idea! [Q]: how to collect the instantiations that happen within the contracts (-> new)? One option is to inspect transaction traces. Geth provides traceTransaction API https://github.com/ethereum/go-ethereum/wiki/Management-APIs#debug_tracetransaction which is available only for transactions executed while running in full archival node mode. ...


3

The light client does not download state data. It downloads the header chain, and verifies the proof-of-work but not the transactions themselves. Each block includes a state root, which allows it to verify state data against the block without having to verify the transactions. When you make an RPC call against a light client, it requests the state data from ...


3

First, it should be noted that there is no such thing as a "plain Merkle Trie". The Merkle tree found in Bitcoin is not a radix tree (trie). The main reason Ethereum uses a Patricia Trie for transactions is simply uniformity. The current protocol specifies exactly one kind of tree-like data structure. Switching to a standard Merkle tree would require ...


2

Let's take a pseudo-code example: x00: {balance: 1} x01: {balance: 2} x02: {balance: 3} x03: {balance: 4} You calculate the first-level nodes: hashOf("x00: {balance: 1}", "x01: {balance: 2}") -> node1 0x1234 hashOf("x02: {balance: 3}", "x04: {balance: 3}") -> node2 0x5476 You then calculate the second-level node(s): hashOf("node1 0x1234", "node2 0x5476"...


2

In the context of your question, you can think of the blockchain as a database. A database on its own cannot "send data to the external world" - it requires some script to query the database and then make the information that is returned available for example via a web interface to the rest of the world. Your interface with the world, may be hosted ...


2

Yes, this is correct. Everything on the blockchain is public, but only the current state is visible to smart contracts. Interestingly, using a Merkel proof, you can prove to a contract that another contract has or had a particular value during any block in the past 256 blocks, since the contract can access the past 256 blockhashes. One little correction: ...


2

This code can be usfull. It will call all constant methods of contract and print their results. If you make all data members of contract public (in development phase of course) compiller will generate getter methods for you, that will be constant functions. This code will not print mapping and arrays, because getters for them expecting keys or indexes. All ...


Only top voted, non community-wiki answers of a minimum length are eligible