August 19, 2026

Capitalizations Index – B ∞/21M

Matter Labs infrastructure tests – Matter Labs –

Matter Labs infrastructure tests – Matter Labs –

Over the first weeks of May 2019 we, Matter Labs, have performed a series of infrastructure tests to evaluate the performance of consistency of our alpha version of ZK rollup (original Twitter discussion, thanks to Vitalik Buterin for great questions). Parts of the infrastructure that were tested included:

  • Ethereum events monitoring from the smart-contract to work with deposits from end-users.
  • Bookkeeping server — one that actually holds the balances and performs transaction processing.
  • Provers cluster — a swarm of prover instances that asynchronously generate proofs based on blocks that were created by bookkeeper.
  • Committer — simple service that is responsible to send commitments to new blocks (with public data) and proofs to Ethereum network for verification by the smart-contract.

As a result of the test we concluded that “Committer” should be significantly improved as it caused delays for transaction inclusion when test was attached to Ethereum Mainnet.

Simple block explorers are available for Mainnet and Rinkeby as a historical record of all the transactions done during the test. Block size was set to 256 transactions, with some share of which was “padding” transactions that do not transfer any value, but inserted in a block if a certain time has elapsed since a previous one. Difficulty of proof generation does not depend if some transaction are only for padding or not due to the nature of zkSNARKs.

Based on the questions from the Twitter we’d like to replicate answers to those in this blog post too.

Why there are two different transactions (“Commit” and “Verify”) for each produced block?

– The system we are building should support multiple “validators” (block producers), so “Commit” transaction indicated the public data that can be used by other “validators” to update their state and be ready to come forward and process the transactions while the actual proof is being produced.

Why to commit public data on-chain?

– For an account based model (that we use for our system) there is no construction that would allow efficient resolution of the worst case scenario when network is either no longer functional (all “validators” are offline) or act maliciously by not publishing the content of the block and not processing “exit” transactions. In the latter case the global state of the system is still correct because it’s proved by zkSNARKs, but it’s not publicly known, so end-users can not prove what is their current balance and perform an “exit” by on-chain interaction with a smart contract. This is a classical “data availability” problem and it arises in most of L2 solutions.

– Enforcing “data on-chain” solves the data availability problem in this case. This also leads to an economical benefit: in case of “data off-chain” security of the network is guaranteed by the valuation of the network or security deposits from operators, along with a game-theoretical “exit” procedure that would allow users to 1) withdraw their funds 2) slash deposits from operators or value of the network. Usually such procedure also enforces a large delay for “exit” to be finalized. On the other hand, “data on-chain” ties security of the network to security of the corresponding L1 network — in this case performing an attack is as hard as breaking the consensus or censoring transactions to one of the contracts.

Proof generation time is expected to be around 5 minutes. This looks like a substantial trade-off on user experience.

– First of all, this 5 minutes delay is (almost) complete finality for our system because as soon as some block is proved to the smart-contract in Ethereum network it can no longer be rolled back. We would allow blocks that are committed but not yet proved to be reorganizable (in cause if some “validator” goes offline in a middle of a process of proof generation), but proven blocks are as final as a state of Ethereum itself.

– Such proof generation time is tied to the current state of the Ethereum at the moment — verification of zkSNARK proof is quite expensive, so blocks should be made quite large. We expect the EIP1108 to be introduced in the next Ethereum fork. That would, along with an efficient batch verification, allow us to have much smaller blocks with faster proof generation.

– Regardless of the outcome with EIP1108 we are working to introduce “instant confirmations” for “transfer” transactions. Such confirmation is a commitment from “validator” to include a transaction in specific block. For a transaction with a small amount user can treat such confirmation as sufficient and if this transaction is not included in a block then “validator’s” security deposit may be slashed.

Published at Tue, 21 May 2019 11:06:08 +0000

Previous Article

Bitcoin Rebounds To $7,900, Why Analysts Expect Bullish Continuation

Next Article

Bitcoin Exchange Kraken Raises $6M Equity Funding In 2 Days –

You might be interested in …

Spectre. Ai | financial trading platform review

Spectre.ai | Financial Trading Platform Review

Spectre.ai | Financial Trading Platform Review Spectre.ai is a financial trading platform built on the Ethereum network. It is broker-less, decentralised, and fraud free. Trade Cryptos, Forex, Equities, Bonds and ETF’s with high liquidity. Demo […]

Op Ed: User Activated Soft Forks and the Intolerant Minority

Op Ed: User Activated Soft Forks and the Intolerant Minority

It does not take a majority to prevail … but rather an irate, tireless minority, keen on setting brushfires of freedom in the minds of men.
Samuel Adams

In The Most Intolerant Wins: The Dictatorship of the Small Minority, Nassim Nicholas Taleb describes how a strong enough minority with more strict preferences can end up with the majority following their preferences. He speaks of many examples  —  food preparation standards, languages and taboos.

This principle can also extend to bitcoin and the concept of soft forks. By extending this principle, it can show that a soft fork that has strong support from a minority still may be enough to provide economic incentives to its enforcement, even if the majority is ambivalent.

Soft forks, by their nature, are a form of intolerance. Users who enforce a soft fork are intolerant of some types of transactions or blocks that miners can produce. They will reject those blocks that miners produce much as an Orthodox Jew will reject pork. In cases where the majority is ambivalent and the cost for producers is low to adhere to the stricter standards, then the result is producers keep everyone happy by following those stricter standards.

In bitcoin’s case, many potential soft forks fall into this category. Soft forks that do not degrade the security properties of bitcoin, that do not take away from any currently used features, do not add costs to miners, and are preferred by some, would result in profit-maximizing miners choosing to serve a wider audience by enforcing the soft fork.

Strong-Willed Minority vs. Ambivalent Majority

In the above case, if there were strong believers committed to a soft fork with stricter rules, miners face a choice  —  do they allow the chain to split or serve everyone with the new stricter rules? If they allow the chain to split, they must pick a subset of users to serve, giving them less value than if they were to serve all. This also harms the network effect, which means the sum of the two parts is now worth less than the original. Thus, as long as the minority committed to the soft fork was sufficient in size that they cannot be ignored, a profit-maximizing miner will follow them (assuming there is little to no cost of enforcement).

Strong-Willed Minority vs. Miners’ Interests

In a case where a strong-willed minority requires non-GMO, organically certified food, this may not result in the minority getting its way. The cost of production may be too high to be worth it. A theoretical soft fork that reduces the block reward by half would be a good example. A minority may feel the block reward is too high and wish that it be lowered, and only allow miners to claim 6.25 coins instead of 12.5 per block. In this case, miners would give up a significant amount of income to have to enforce it, and the loss of “business” from excluding these users may be less costly than reducing their income.

Strong-Willed Minority vs. Strong-Willed Minority

A third case is when a strong-willed majority ends up alienating another portion of the potential consumers. If a new religious sect required that all food have bacon added to it, Jews and Muslims would not tolerate this and would splinter off, even if the majority did not care either way. In this case, a split is inevitable.

In the bitcoin case, some users may wish to have all addresses logged in a government registry to ease KYC compliance. They could demand that miners only mine blocks that adhere to these standards. This type of action would be rejected by many users who would not go along with such a plan, and in fact may even take steps to block it if it was enforced. In this case, a split would be inevitable if both factions were sufficiently intolerant of the other.

The Importance of Commitment and Stubbornness

This only works if users are absolutely committed to their rules being followed. Commitment must be absolute and unwilling to change, no matter what the majority does. The most important part of the intolerant minority is to truly be intolerant! If the cause is not worth putting your neck on the line for, it will not be successful.

Some supporters of user-activated soft forks (UASFs) have stated that they intend to enforce the UASF unless it is not widely supported or followed, and then would back off. This is the surest way to guarantee failure. If you are unwilling to follow a minority chain with an economic minority, you aren’t truly an intolerant minority. You are only one with a preference.

Guidelines for User-Activated Soft Forks for Maximizing Success

  • Take away no existing useful features (do not create a hostile minority).

  • Do not add significant costs to miners (make burden for miners as low as possible).

  • Include functionality that users are willing to fork off for.

  • Ensure there is a sufficiently sized minority willing to commit.

A sufficiently sized, committed, economic minority is enough to have a successful user-activated soft fork. While Shaolinfry said that without an economic majority behind a soft fork, it should be withdrawn, I believe that statement to be too weak. The history of intolerant minorities making changes is long enough to show otherwise.

This guest post by Alphonse Pace was originally published on Medium and is reproduced here under Creative Commons license. Some rights reserved. The views expressed do not necessarily represent those of bitcoin Magazine.

The post Op Ed: User Activated Soft Forks and the Intolerant Minority appeared first on Bitcoin Magazine.

Rapper Mims to Promote ‘Tune’ Token for Artists

Altcoin Today Rapper Mims to Promote ‘Tune’ Token for Artists Rapper Mims to Promote ‘Tune’ Token for Artists Award-winning rapper Mims has become the latest musician to launch a blockchain company. The artist has co-founded […]