Question regarding scaling

[sirpy]

This looks like a very interesting project. Personally i'm interested in scaling voting. But I could not understand how this can scale since in order to be able to create a dispute all txs or if verifying just aggregated signatures then all pubkeys must be stored on chain. even if we compact the pubkeys to 20bytes then just 100 would be 2000bytes which is roughly 6232bytes costing 20,00062 = 1.2M. Am I missing something here? can you elaborate on scaling and gas costs?

[vaibhavchellani]

Thanks for checking out hubble! 🤝

Here are some details that might help with your questions,

• We don't store pubkeys on-chain, we store the pubkeys as a leaf in a merkle tree we call AccountTree so that helps with the gas cost since we store only the root of this merkle tree on-chain.
• Dispute only runs in the worst-case scenario and we are trying really hard to keep the gas cost low for that too.
• The final goal of the project is to have multiple hubble rollups in the same orbit, by which I mean that you deposit once into the ecosystem and then you can move to any rollup in the orbit without any L1 transaction. So your deposit cost is amortized.

We run benchmarks with every PR via the CI, our latest merge shows 2600TPS which I think on par with other solutions.

[sirpy]

ok well not the pubkeys, in your case its the list of txs, in order to create a dispute you need the TXs list to be submited with every state change, otherwise it is not possible to verify the state change (only in a case of dispute of course). I also saw in the code that the tx list is submited with every state change.

also in the bls docs I saw somewhere is that it can scale nicely if the same message is signed by multiple signers but grows linearly with each message, so my question is, how is that scaling for txs? I assume each TX is a different message no? or the bls signatures is used for something else?

[ChihChengLiang]

Hi @sirpy, Yes, transactions are different messages to sign. The optimistic rollup improves the throughput by reducing the gas cost in the "submit batch" stage as much as possible. Using BLS signature, we can use fewer calldata than ECDSA.

Specifically, ECDSA needs 65 bytes for signature in the calldata, for each message. If we have n transactions, that would cost 65 16 n gas in total. In contrast, BLS costs only 64 bytes in total for any number of messages.

That said, you can see we have multiple signatures in the submitX functions. That's because we have a batch/commitment separation. A batch is the max number of transactions we can submit in an eth1 transaction, while a commitment is the max number of transactions we can dispute at once. To make the commitment disputable, we still need one signature per commitment.

[sirpy]

@ChihChengLiang thanks for the quick response ok so we save that space that is required by signatures, but the txs in the batch/commitment needs to be recorded on chain no? and each tx must have from,to,amount which lets say needs just 10 bytes, what am I missing in terms of data size that is required to be stored on chain?

[sirpy]

@ChihChengLiang ok so now i see that the TXs are actually not stored on chain , and are just used to compute a merkle tree. but lets say i want to dispute some TX, where do I get that TX data if I dont have it on chain? also how is denial of service handled? ie the submitter doesnt include certain TXs? basically just "rage quit"? the user leaves with his funds?

[ChihChengLiang]

Tx data is available from the calldata, here's how to parse them https://github.com/thehubbleproject/hubble-commander/blob/b3ca690732414829f086b01e9d0334b47adbdac9/bazooka/calldata.go#L154

how is denial of service handled

This is where burn auction comes in. An honest coordinator can outbid the malicious one to serve users. The auction result also reflects the cost of censorship, so people can know how expensive to censor/uncensor.

[ChihChengLiang]

Transferring this to discussions