Enforce limits on # of parties, events, & sequence events to match those defined by the protocol

[jasongitmail]

No description provided.

[jasongitmail]

Ideally we throw a compile time error

[Comdex]

Hey! I don't know whether it is appropriate to ask here, because I only found this relevant open issue. How many fields is the limit size of each event and sequence event? And what is the total limit size of events and sequence events in each transaction?

[mitschabaude]

there's no extra limit for the number of fields in one (sequence) event, but there'll be a limit on the total number of all fields in all events / sequence events. We're still in the process of deciding the exact number, but it'll be about ~20-30 I think

[Comdex]

there's no extra limit for the number of fields in one (sequence) event, but there'll be a limit on the total number of all fields in all events / sequence events. We're still in the process of deciding the exact number, but it'll be about ~20-30 I think

Personally, I prefer this limit >= 30, which I think would be more friendly to some privacy use cases based on the UTXO model, such as coin mixers.

[mitschabaude]

Most of these limits will be fairly tight, because the time budget for snark workers to create proofs becomes much tighter with zkApps

[jasongitmail]

Gregor explained well. We're trying to be conservative initially and then can potentially increase limits over time

[bkase]

Ask @deepthiskumar for the formula for the limits and translate the formula to the client side

[bkase]

The constants will probably change, but the formula probably won't change much