Error contexts

[sayon]

🌟 Feature Request

The errors communicated from zkos need to have more context data attached. This includes both data for zkos/sequencer devs and data for end users.

📝 Description

Requirements:

• Compatible with both RiscV and normal architectures with minimum effort and maximum consistency
• For RiscV:
  • nostd and nonstandard allocator, that has to be requested from an instance of System.
  • minimize footprint
  • minimize cycles
  • sufficient error information to debug divergences
• For normal target
  • may have standard allocator
  • may have bigger footprint
  • possibly optimized for high performance in high TPS context (but we don't want to assume zkos is the bottleneck)
  • maximal debuggability for us, devs
  • public information about errors passed to the sequencer, so that the sequencer can wrap it into user-level errors.

Currently errors are very lean on RiscV but on normal architectures they start to get large enough for Clippy to shout at the large Results (because of error locations/traces). So before we end up with errors forcing us to copy kilobytes of data, we need to account for this. Users want to know contract addresses, balances and other data with wide types.

Proposed solution

Errors are associated with three kinds of information:

1. Public, interesting to end users
2. Debug, interesting to zkos/sequencer devs
3. Essential, needed for decision making in zkos and distinguishing between errors.

Key insight:

• Sequencer in release builds needs only (1)
• Sequencer in debug builds needs (1) and (2)
• RiscV build needs only (3)

Implementation:

1. Errors are defined so that they own only essential information in the datatype fields.
2. Errors hold a feature-gated field with a Box of contexts (or empty struct if the feature is disabled). It allows accessing debug and release parts of the context.
   • The contexts are allocated using the default allocator , this is compatible only with normal builds, not RISCV builds.
   • Using a custom allocator to make it compatible with RiscV is possible but will require passing it everywhere, and this change would be very intrusive in the current codebase.