Hi!
Just a quick question. I know that on ETH they have a gas limit because of the block size. My understanding is that you cannot submit a transaction that surpasses this limit. Does concordium have something similiar? Is there a limit to how much NRG one transaction can use. I have tried looking in the whitepaper for at limit, but cannot seem to find any.
Thanks.
Hi Honro
The limit is 3 million energy per block.
Regards,
Concordium Tech Support
Thanks for the answer.
Just to clarify, does this mean that a transaction that uses more energy than 3 mil will be rejected, or will it be split between more blocks?
I asked one of the members of the Science team, and he said it will be just rejected.
You got some counter questions:)
In which case, which transaction would use that amount of energy? From the cost side…who would use that big amount of fee for one transaction?
Alright.
We are implementing the Open vote network protocol, which in order to find the result of an election, brute forces the number of yes votes. This means we have a function that does as many elliptic curve additions as number of yes votes. This is quite costly and scales linearly with the amount of yes votes.
This is the computation that proves to be expensive with many participants.
We were just curious, since this would be a cap on participants in our protocol:)
To add a bit to what Zoltan wrote, the 3 million is a genesis parameter. That is the limit on testnet and mainnet. This limit is necessary since blocks must be executed in a reasonable amount of time so that all network participants can validate it before new blocks are baked to avoid excessive branching.
When you send a transaction you specify the upper bound on how much energy it can use. If this upper bound is more than the block energy limit the transaction will be immediately rejected by the node, i.e., it will not even be stored as a pending transaction.
What you are doing does sound quite costly indeed. What curve are you doing your arithmetic in?
One potential option for you would be that you yourself would split the computation across multiple transactions, e.g., partition the set of participants into a tree and then add them in steps that fit into a block.