Nyzo techQuick tipsCycle TX & balance list size

Cycle TX & balance list size

Beginning with blockchain version 2, cycle transactions and their signatures are stored in the balance list pending approval.

Each verifier in the cycle is only allowed to have a single pending cycle transaction at a time. If a verifier submits a new cycle transaction, it will replace the current pending cycle transaction proposed by that verifier. So, the number of pending cycle transactions is limited to the number of verifiers in the cycle.

Each verifier in the cycle is only allowed to have one current vote for a pending cycle transaction. If a verifier votes again for a cycle transaction, the new vote replaces any existing vote. So, the number of votes per cycle transaction is limited to the number of verifiers in the cycle. Due to the ∩100,000 limit in cycle transactions per 10,000 blocks, a cycle transaction can remain in the balance list with greater than 50% of the cycle's votes.

While the number of cycle transactions and number of votes per transaction is strictly limited relative to cycle size, the limit is proportional to the square of the cycle size. This is not a vulnerability, because any attack would require a large portion of the cycle to participate.

Nyzo is designed to scale to very large balance list sizes, and balance lists are not transmitted outside the initialization process. So, the artificial 4 MB message limit and 300-millisecond message timeout do not affect the normal operation of the system*.

In the interim, those experiencing problems with their verifiers due to balance list sizes should upgrade their instances. Also, if any cycle transactions are approved, they will be removed from the balance list, which will lighten computational and memory requirements. Alternatively, resubmitting a cycle transaction that has a large signature list will result in clearing of the existing signatures, which will also reduce the size of the balance list.

*To aid in automated configuration and scaling of block sizes, plans are being made for a separate large-message port than can be used to handle large balance lists, large blocks from in-cycle verifiers, and trusted requests for scripting without requiring loosening of the requirements for the standard port. This port will also be available to whitelisted addresses to allow privileged communication.