tl;dr;

Our main purpose at SKALE is to create a decentralized permissionless cloud that is ETH-compatible and uses the ETH mainnet as a secure foundation. When the SKALE production network goes live, anything you can do on AWS, you should be able to do in a cheaper, more reliable and decentralized way on ETH+SKALE.

Since the ETH mainnet is so important to us, we are interested in speeding it up, allowing for faster finality with greater UX, and giving options to maintain Layer 1 security guarantees. We don’t believe the long-term answer to effectively scaling Ethereum should rely exclusively on the validator set of the mainnet, however, integrating mainnet reliant scaling mechanisms for appropriate use cases is a major requirement for SKALE to have a “full set” of scaling techniques.

Eleven months ago, we discovered BLS-ROLLUP which is an efficient and secure way to use the SKALE network to speed up transactions and smart contracts on the Ethereum mainnet, while preserving Layer 1 security guarantees.

Today we are announcing a decision to include BLS-ROLLUP into the SKALE production network. Every SKALE validator will participate in BLS-ROLLUP and profit from BLS-ROLLUP fees. It is an exciting money making opportunity for our beloved validators!

BLS-ROLLUP:

  • is instantly secure and cheap
  • does not require any waiting periods
  • does not need computationally heavy zkSNARKS/STARKS

It just works.

Rollups are not silver bullets to scaling as they don’t fix latency issues (detailed at end of post), but they can greatly improve throughput and lower costs.

When making design choices for BLS-ROLLUP our guiding principle was “Make something people want” as per Paul Graham of Y Combinator. It is not enough to make something run fast. It is equally important to make it usable.

BLS-ROLLUP will come in two phases:

  • In Phase 1, we’ll use the SKALE network to help the ETH mainnet to get a bit speedier. This gives us about fifty transactions per second for ERC-20 token transfers.
  • In Phase 2, we’ll use the SKALE network to help the mainnet even more, which gives us around 350 transactions per second.
  • The long term goal accompanied with some heavy software development lifting for Phase 3, will give well over a 1000 transactions per second, matching or exceeding the total speed of the upcoming ETH 2.0 network.

What does this all mean in simple terms? Essentially we will be able to support all of the “meaningful-size” consumer transactions globally for years to come, while smaller, more frequent, finality important micro-transactions can be performed on sidechains.

The unique advantage of the SKALE approach is that all account balances are stored on-chain and all computation is performed on-chain. It is really a solution that sticks to the Layer 1 network as much as possible.

Excited? Keep reading! At any time you can tweet a question to @stan_kladko.

1 | Bird’s view of BLS Rollup

The core idea of BLS rollup is to make transactions smaller. If you make transactions smaller, you make blockchain faster. Here’s why:

Imagine a ferry that goes every hour between Tiburon and San Francisco. Suppose the ferry can fit 100 cars, the throughput is 100 cars per hour.

Now imagine you made the cars smaller so that the ferry can hold 1000 cars. The throughput then becomes 1000 cars per hour. Ten times more.

The moral is that the smaller the cars, the higher the throughput.

Now an ETH block is your ferry, and ETH transactions are your cars. Making an ETH transaction ten times smaller will make the throughput 10 times higher.

How can we shrink a transaction? Read the next section!

2 | Shrinking an ETH transaction

What’s the size of a typical ETH money transfer transaction? The answer is 100+ bytes. Out of this, a significant portion (about 64 bytes) is the ECDSA signature of the transaction. Another big portion of a transaction is the 20-byte address of the receiving wallet.

The first step to shrink the transaction is to use a 4-byte UserID for each user instead of the 20-byte address. When a user registers for BLS-ROLLUP, she will get a UserID assigned.

The second step is to remove the ECDSA signature altogether. How can this possibly be done? We use the magic of a crypto algorithm called aggregated BLS signatures. If many parties sign a document, the signatures can be magically glued together into a single aggregated BLS signature. This BLS signature takes way less space than the original signatures.

We call a party that glues signatures together into a BLS signature an aggregator.

Here is how you can think about it. Imagine people that send tiny letters from San Francisco to New York in really large envelopes. That’s inefficient! Now an aggregator is someone who gets a pile of envelopes, takes the letters out and puts all of them in a single envelope. Much more efficient!

Now, on blockchain, a letter is a transaction and an envelope is a signature. We call this aggregation technique BLS-ROLLUP Phase 1.

Read the next section to dig into details.

3 | BLS-ROLLUP Phase 1: Aggregation protocol

First, we need to select an aggregator.

We can’t let a single node be the aggregator, since this node may become a dictator and start censoring transactions.

What we do instead, is split time in 10 minute epochs, and randomly select an aggregator for each epoch. Note: there is a more advanced version of the protocol where several aggregators are selected for each epoch, but let's stick to the simple thing.

Imagine a crowd of people (the SKALE network). We randomly pick, say, Diane, and make her work as an aggregator from 10:00 am to 10:10 am. And for the following time slot another person is selected.

The Six-Step Aggregation-Protocol (SSAP) then goes as follows:

  1. Users submit transactions to the aggregator Diane.
  2. Diane glues transactions from a large group of users G into a chunk-of-transactions C.
  3. Diane sends C back to every user in the original group G.
  4. Every user John on receipt of the chunk C, signs it and sends the signature S back.
  5. When Diane receives back the signature from every user, she glues them into a BLS signature BLS_SIG. Now the chunk of transactions C and BLS_SIG become “many letters in a single envelope”. Lots of space saved!
  6. Now Bob submits C and BLS_SIG to the mainnet.

How fast can the aggregation protocol go? Well, users will use either browsers or mobile apps, and the aggregator will use a web server. The interactions of the web server with users will go in parallel, and having the typical internet speeds of today, the entire aggregation procedure will take several hundred milliseconds.

Now, what if John becomes malicious and does not submit signature S in step 4? Turns out there are two very effective ways to fight this:

  • First, the aggregator can take John’s transaction out of the chunk and restart the aggregation procedure. The aggregator than records a bad rating for John on blockchain. After John’s rating goes below a certain limit, he is kicked out of the system. Think of Uber. If you keep on calling Uber and not showing up, your passenger rating will go down and at some point you won't be able to use Uber anymore.
  • Second, if everyone signed, but John did not sign, the aggregator can submit the chunk C to the mainnet and mark John as a non-signer. John’s transaction in the chunk will simply be ignored by the blockchain.

Let’s summarize what actually get submitted to the blockchain:

  • First, many many transactions, around 12 bytes each (four byte source, four byte destination, four byte amount).
  • Second, a single signature BLS_SIG that secures all these transactions.

Voila!

Now once the chunk C and BLS_SIG are submitted to the mainnet, the processing is very simple! Read the next section to see what happens.

4 | BLS-ROLLUP Phase 1: Mainnet processing

Once the chunk of transactions C and the signature BLS_SIG arrive on the mainnet, a smart contract processes the transactions. We call this smart contract BLS-ROLLUP Manager or BRM.

Here is what BRM does:

  1. Verifies that BLS_SIG is valid.
  2. For each transaction in the chunk,
  • reads the amount of the transaction Amount
  • decreases the balance of the sender by Amount
  • increases the balance of the receiver by Amount

Voila!

Now, how much gas does BRM processing consume? A back-of-the-napkin calculation in Appendix A gives around 13,000 gas per transaction for an ERC-20 token and 7,000 gas per transaction for an NFT token. Compare this to the current ERC-20 token transfer price of around 52,000 gas.

Having the block gas limit of 10,000,000 per block and 15 second average block time, we arrive at around 50 tps for ERC-20 token transfers and 90 tps for NFT token transfers.

We expect BLS-ROLLUP Phase 1 to go into production in the first half of 2020.

BLS-ROLLUP Phase 2 will be ready around summer 2020 and will provide more dramatic speedups. It is described in the following section.

5 | BLS-ROLLUP Phase 2: Use cheaper storage

If we want to make things even faster, we need to drive down the gas-per-transaction. Remember that in BLS-ROLLUP Phase 1, we got it down to 13K from 52K for an ERC-20 token transfer.

The key observation is that, out of 13K, 10K comes from updating sender and receiver balances in EVM storage. Each EVM stored value update costs 5K gas.

Does the ETH mainnet have cheaper storage? It turns out, yes, and it is called Log Storage. Log Storage costs 375 gas per storage event plus 8 gas for each byte of data.

Why don't we just use Log Storage instead of EVM storage? It turns out that Log storage can’t be read from EVM. You can write into Log Storage from EVM, but read it only from outside of the EVM.

So here comes an idea: each time the EVM needs to read from storage, SKALE network will read it and push it into the EVM. Voila! Now we can use Log Storage.

The details are described in the following two sections.

6 | BLS-ROLLUP Phase 2: Storage format

In BLS-ROLLUP Phase 2, funds are stored in Log Storage using Bitcoin-like coins, called UTXOs (Note, that Plasma also uses UTXOs). Each user owns a number of unspent coins, and the total balance of a user is the sum of all coins owned by the user.

Each transaction spends multiple input coins that belong to the sender and creates two output coins — one that represents funds passed to the receiver and another that represents the remainder of the sender’s funds.

As an example, if Alice wants to pay 4 tokens to Bob, she may spend three of her coins: 1 token, 1 token and 3 tokens and then create two coins: one in the amount of 3 tokens that is passed to Bob, and one in the amount of 1 token that she passes to herself.

The actual Log record corresponding to this transaction will have the following format:

{transactionCounter, input_coins, output_coins; topic(sender:Alice), topic(receiver:Bob) )

Here transactionCounter is the sequence number of the transaction, input_coins represents amounts of input coins and locations of corresponding log records on blockchain, output_coins represents amounts and owners of output coins.

Topics have a special purpose in EVM, namely, EVM provides an easy way to search log records by topic. We add two topics sender and receiver so that a user can easily find all of her coins.

The gas cost of a log record corresponding to a single transaction described above is around 1300 gas. Way lower than in Phase 1, where updating sender and receiver balances consumes almost 12 000 gas!

So we got the storage costs down significantly. Now we need to help EVM read the records when the time for a transaction comes. And here the SKALE network helps the mainnet as described in the next section.

7 | BLS-ROLLUP Phase 2: The SKALE Network helps the Ethereum Mainnet

The main idea is that when the time comes to read a log record, nodes from the SKALE network read it and push it to the mainnet. To be Layer-1 secure, we need at least 111 random nodes from the SKALE network to do the read, and then sign it using a BLS two-third-supermajority aggregated signature. Why 111 nodes? Because for ETH 2.0, it is accepted that a committee size of 111 nodes is Layer 1 secure. We do not keep this set fixed forever. Instead, we slowly and randomly rotate its members so that ultimately every node in the SKALE network gets to participate in the set.

We then take the SSAP aggregation protocol described in Section 3, and introduce an additional step 1 1/2 that an aggregator performs in between Step 1 and Step 2 of the aggregation protocol:

Step 1 1/2 : When the aggregator receives a pending transaction from Alice spending some coins (UTXOs) and transferring money to Bob, she passes to the 111 validators nodes the pending transaction.

The role of the validators is simple: they verify that the transaction is correct, spend valid coins and do not attempt a double-spend.

In more detail, each validator node will:

  • verify that the UTXOs cited in the transactions exist on blockchain, have the correct amounts and are unspent in the usual Bitcoin sense (meaning that there are no later transactions mentioning these UTXOs as inputs)
  • verify that there are no other pending transactions attempting to use these UTXOs (when a validator receives a transaction it saves it as pending)
  • sign the transaction using an aggregated BLS validator signature and pass it back to the aggregator
  • the aggregator will then include the validator BLS signature when submitting the transaction to the blockchain in Step 2.

Once the transaction is received by the BRM smart contract, it will verify BLS signature of validators and then process the transaction creating a UTXO Log record as discussed in Section 6.

When we estimate the total cost per transaction we get around 1600 gas: 1300 is log record creation costs discussed above, 190 gas comes from the need of BLS public key aggregation per transaction, and 100 gas comes from other operations.

8 | BLS-ROLLUP Phase 2: Performance

Our back-of-the-napkin calculation for overall per-transaction cost of BLS-ROLLUP Phase 2 puts us at around 2 200 gas per transaction for ERC-20 token transfers. Compare it to 51 000 gas for ERC-20 token transfers today. This corresponds to 300+ transactions per second while preserving Layer 1-like security at 5% of the normal cost.

But it is not only performance that matters. BLS-ROLLUP keeps all information and computations on the mainnet, and only uses SKALE Network to help the mainnet, where needed. This means that it will work with the current infrastructure and will require minimum modification of existing web and mobile clients.

9 | BLS-ROLLUP Phase 3: Pushing it to the limit

At 300+ transactions per second, BLS-ROLLUP Phase 2 is pretty fast and can support ecosystem growth for many years. Note that today, the ETH mainnet does less than 10 token transfers per second, and BLS-ROLLUP has similar latency to the mainnet.

There is still a way to improve BLS-ROLLUP to make it faster (although we do not envision doing this earlier than in the next few years).

The key is to use the smallest transaction size possible and record many UTXOs in a single log record. This saves us 1125 gas fixed cost of creating a record, but makes UTXO records unsearchable using the standard EVM topic-based search facility. Users won't be able to easily find out how much money they have. We address this problem separately adding an external search and indexing engine to each SKALE node.

In order to find her coins, Alice will need to search the mainnet. To do this, the user will need to either talk to one of the SKALE nodes or to other providers (such as Infura), or run the indexing engine herself.

A back-of-the-napkin calculation for Phase 3 gives 700 gas per transaction, which corresponds to 900+ transactions per second.

10 | Slashing

The system described above provides easy evidence of mischief and slashing of malicious validators. Fraud proofs can be submitted to the mainnet and malicious validators can be slashed. Since this blog post is already quite long, we leave it to the reader to think about slashing conditions, since they are quite obvious.

11 | Final thoughts

BLS-ROLLUP provides a way to significantly scale transaction rates on the mainnet, while staying within Layer 1 security guarantees, and storing user funds on the mainnet. SKALE network plays the role of a helper Layer 1 network that helps the mainnet.

BLS-ROLLUP is the only rollup that does not require any user monitoring, wait periods or dispute resolution. This makes it a better and more user-friendly solution.

BLS-ROLLUP can be very successfully used for money transfers and large purchases. Since it is based on the mainnet, it still suffers from the slow finalization of the mainnet. Users need to wait for 5+ minutes to deem a transaction on the mainnet successful. It is OK if you are buying a car, but not OK if you’re buying coffee. If you want to buy coffee, you should use a sidechain.

* Appendix A

Phase 1 per transaction gas cost estimate per ERC-20 transfer transaction (after Istanbul and Berlin forks):

  • read sender balance: 800 gas
  • read receiver balance: 800 gas
  • sender balance update : 5000 gas
  • receiver balance update: 5000 gas
  • read sender BLS public key: 800 gas
  • add sender BLS public key to get the aggregate key: 190 gas
  • Total: around 13,000 gas

Phase 1 per transaction gas cost estimate per ERC-721 NFT transfer transaction (after Istanbul and Berlin forks):

  • read current owner address: 800 gas
  • current owner update: 5000 gas
  • read current owner public key: 800 gas
  • add current owner BLS public key to get the aggregate key: 190 gas
  • Total: around 7000 gas

* Appendix B

Phase 1 per transaction gas cost estimate per ERC-20 or ERC-721 NFT transfer transaction (after Istanbul and Berlin forks):

  • UTXO log record: 1300 gas (375 log event + 2 * 375 gas for two topics + data)
  • BLS public key aggregation: 190 , out of which 150 elliptic curve addition + 40 gas precompiled call
  • Call data: up to 300 gas for up to 18 bytes of call data
  • Computation: less than 50 gas

Total: around 2200 gas

* Appendix C

  • The minimum size of a typical transaction is roughly 20 bytes since it needs to include sequence numbers of two input UTXOs, the index of the receiving party and the amounts for the two coins that are created. This requires 320 gas in call data event, since call data is 16 gas per byte.
  • BLS public key aggregation requires 190 gas.
  • Log record size is roughly 20 bytes since it needs to include sequence numbers of two input UTXOs, the index of the receiving party, index of the sending party and the amounts passed to each party. This requires 160 gas at 8 gas per byte.
  • Computation: less than 50 gas

The total then becomes around 700 gas