Blockchain Scalability: Chain-Fibers Redux | Ethereum Foundation Blog

history

The first seeds of this idea came to me in the spring of 2014 when I was talking to Janislav Malakhov in Berlin. Unfortunately, the original article I wrote was stolen in Vienna and lost along with my laptop. Recently, after discussing the principles with Vitalik, we have made a number of changes and formalizations, mainly to the validation and substate disconnection mechanisms. Below is a fairly complete picture of one particular possible plan for block chain scalability in new versions of Ethereum.

This is by no means a final proposal, so GitHub Wiki Page This will track the progress of this particular idea.

overview

The basic idea behind Chain-Fibers hasn’t changed from a year ago. Partition the state space into hierarchies, with separate transaction matchers specialized for one or more state subspaces. Transactions that require interactions from many subspaces are correspondingly more costly (because the matchers must maintain presence on multiple chains) and take longer to execute (because the is unlikely to contain a superset of the transaction subspace). The validity of a transaction can be independently verified by providing a comprehensive Merkle proof for the input along with the transaction within the block that contains it.

The subtlety is what exactly controls the subspace partitioning (my original proposal included automatic splitting, merging, and rotation of the subspace partitioning to best achieve internal consistency) ), how to maintain security within relatively worthless subspaces, and how well this works. Proof-of-Stake (originally based on the master PoW chain, he borrows from ideas proposed by Max Kaye in early 2014 to decouple blockchain archives from migration semantics).

The basic idea is to have a large number of chains (e.g., N), each of which details the state transitions of only a hierarchy of the entire system state (i.e., state subspace). Following programming terminology, these may be called “fibers”. Therefore, an account belongs to a subspace and belongs to a single fiber. The fiber to which they belong can be easily determined from the first log2(N) bits of the address. N is a value that can be increased or decreased and is maintained in housekeeping information on the “master chain.”

The master chain is maintained by a set of coupled validators, V, where the number of validators is proportional to N. Randomly selected validators verify each block generated, and the validators ultimately vote for consensus on the master chain. Each block in the master chain maintains a reference to each fiber’s header.

Transaction matchers generate blocks (receiving fees from transactors) and pay a portion of the collected fees to validators for including the hashes of the blocks in the main chain. Blocks are generated across a specific “home set” of fibers. This is basically just a set of fibers that maintain state tries. Those blocks may contain transactions through one or more of these fibers, but do not contain transactions outside of the “home set”.

“Fisherman” is a word that refers to a freelance checker. Block validation and availability are both important, and since a set of validators may be contractually bribed, we recommend that additional reasonable individuals It is important to have a mechanism in place to engage as a whistleblower. Checking all blocks. The fisher essentially pays to try to convince a quorum of validators that a previously validated block is invalid (or unavailable, assuming this is equivalent). If the fisherman proves that a validator (or more likely, a set of validators) has acted dishonorably, the fisherman will have to claim the entire bond. Fees are paid to avoid her DoS to validators through fake challenges.

circuit diagram

I’m sorry that it’s not very ASCII art. I haven’t reached 1337 in Inkscape as much as Vitalik.



Transactors        ==TX+FEE==>  Collators                     ==BLOCK+FEE==>  Validators
make transaction                 validate transaction,                         random selection chosen to audit
                                produce Comprehensive Merkle                    TX/PSR/CMP contents & availability,
                                  Proof and Post State Root,                  all placed in PoS-consensus master block
                                collate into X-fiber Block
                            Fishermen                 ==CHALLENGE+FEE==>  Validators
                            search for invalid or                         a selection adjudicate challenge
                              unavailable X-fiber blocks



trader

Transactors are much the same as in Ethereum 1.0, they are users of the system.

Trader: Make a trade

Transaction executors execute transactions in much the same way as they do in the existing Ethereum system. One or two small differences – addresses can be used as distance metrics. Those that share the same number of initial bits are considered “closer”. This means greater certainty into the future that they will continue to be included in the same state subspace. Contracts are naturally created within the same state subspace as their creator.

Similar to Collector, transactions run on many fibers. Maybe one, maybe all, maybe somewhere in between. Submission to the matcher may be directed through a fiber subnetwork overlay.

Submissions and payments to matchers will occur in the same way that submissions of existing transactions to miners will occur in Ethereum 1.0.

Verifier

Collator maintains a presence on at least two peer subnetwork overlays. Validators overlay, and one or more fiber overlays. Fiber overlays may provide directional transaction propagation. A collator “collates” a set of fibers. It maintains a complete fiber chain for each fiber it matches and can accept all transactions involving any combination of fiber sets. The larger this combination, the larger the “transaction net”, but also the larger the overall disk/memory footprint.

Matcher: Validate the transaction

When a transaction is received, it goes through the usual Ethereum 1.0 steps of checking whether the payment is sufficient, initial balance, etc. Once the basic validation is done, it tries to run it, but throws it if it touches a fiber that is not part of the matcher’s fiber set.

Collators: Generate comprehensive Merkle proofs and post-state roots.

The collator provides each post-state root (as seen in a transaction receipt in Ethereum 1.0) and the Merkle proof for all inputs (balances, nonces, states, codes) from all subspaces and associated hints (contracts). code) to the block. This is required for the evaluation of each transaction from a previously known post-state root.

This allows the auditor to determine the validity of a block without having to do anything other than the post-state route before each fiber.

Collator: Collates to the X-fiber block.

A cross fiber block is created by combining the collated information. This includes the transaction, the receipt of the transaction (after the state root), the comprehensive Merkle proof, and the associated hash hints. This block does not contain consensus-specific information such as timestamps, uncles, etc.

validator

Validators (perhaps better called auditors) are guaranteed participants who are periodically selected from among the highest bidders and receive a small fee for the final maintenance of the network. Their job as a whole is to form the jurisdiction and final authority over the validity of the chain and the content of transactions. We generally believe that they are mostly philanthropists and not all can accept bribes. Since the surety is insured, it may be required to audit and stake the guarantee on an opinion as to the adequacy or availability of information.

Validators: All placed in PoS consensus master block

They maintain signature control over the master chain. The Master Chain (MC) encodes all PoS/consensus related stuff like timestamps, and is used to record validators’ bond balances, ongoing challenges, fiber block header hashes, and other housekeeping information. Contains its own small state root.

For each master block (MB), a set of matched X-Fiber blocks (XB) is obtained. These should be non-overlapping so that each fiber belongs to only one of her XBs.

Validator: Random selection selected to audit TX/PSR/CMP content and availability

Each MB has several XSBs that are referenced by the MB’s tries. Each fiber is assigned a randomly selected set of validators, who must review all XBs that include the assigned fiber. Verification involves retrieving the XB, finding the previous PSR for each fiber (placed in the MB), ensuring that the proof in the CMP covers all necessary inputs to the internally matched transaction, and the PSR. Contains confirmation that is actually a final state route. Everything runs.

A block is considered valid if all assigned validators sign the block. Signing this is considered an assertion that the contents of the block are valid and available for a probabilistically long “challenge period” during which the fishermen may challenge them. Any challenge to the validity of a block that is ultimately upheld by the full consensus of a randomly selected set of validators (which, if persistently contested, will ultimately result in a majority vote) will be immediately This means you will lose your deposit.

fisherman

A fisherman (sometimes called a bounty hunter) is a freelance error checker for the system. Monitor validators in hopes of catching fraudulent activity. To ensure presence, payouts are designed to be huge. The costs associated with the challenge are small, but not insignificant.

Fisherman: Finds invalid or unusable X-fiber blocks.

Check the X fiber block for validity errors or data unavailability. When we find an invalid block or unavailable data, we launch a challenge (for a small fee paid to the validators) in the hope that enough validators agree. If we are successful and the validator ultimately upholds the challenge, we will receive the deposit of all validators who previously claimed the validity/availability of the information.

Fishermen’s Challenge

  1. Fisherman finds invalid/unavailable blocks that have not yet passed their “challenge period” (10-30 blocks). Pay the fee and submit a challenge transaction to the master chain.
  2. A set of randomly selected validators (e.g. in an order such as sqrt(N)) ++ Any validator that self-selects (by doubling the join), checks the challenged block. Each votes Y or N for the validity of the block.

    • If N, the validator receives a small payment Pn.
    • If Y, the validator stakes the bond but receives a larger payout of Py (probably Py = 2Pn).

  3. The results of the challenge (probably accumulated in the next block) are:

    • The challenge ends if 66% or more of validators vote Y (valid). The fisherman loses his commission, but can start the challenge again.
    • If at least one validator votes Y (valid), the challenge continues with a second, larger set of randomly selected validators. All bonds are staked.
    • If all validators vote N (invalid), the block is marked as invalid and the fisherman receives the deposit of all validators who claimed the block’s validity. This is a huge payoff.
    • Note: If the set contains all validators, it will be a simple majority rule.

Other differences

All addresses are contained in lookup tables specific to each state subspace. This means you can reference them through a small number of bits and avoid wasting a lot of entropy in RLP for things like proofs.

Note

Once a block has passed the challenge period, it is considered unassailable. If a problem is found, it should be fixed in the same way as a protocol upgrade. As such, validators and other large stakeholders may act as fishermen to protect their investments.

Related Article

0 Comments

Leave a Comment