Implement MagicBlock Protocol v2 #132

Goal

Deliver MagicBlock Protocol v2 (formerly Delegation Program): delegation, commitments, verifier approval, fraud proofs, and the supporting account and instruction lifecycle. The new name reflects the program’s scope beyond delegation.

Scope

• Streamline the MagicBlock Protocol v2 delegation account lifecycle #203: streamline delegation and undelegation account lifecycle.
• Implement the v2 commitment and challenge lifecycle #234: implement fraud proofs and supporting instructions.
• Remove commit_frequency_ms from MagicBlock Protocol v2 #239: remove the unused v2 commit-frequency setting.
• Rename delegation-program and dlp-api for MagicBlock Protocol v2 magicblock-validator#1700: rename the program and interface packages and update consumers.
• Cover Delegate, Commit, Finalize, Undelegate, and CallHandler, including their required supporting instructions.

Lower-priority tasks remain in v2; priority determines sequencing, not scope. Conditional work stays conditional—for example, a separate payout claim is needed only when payouts are delayed. Keep v1 interfaces unchanged unless separately scoped.

Keep the fraud-proof checklist in #234, including lower-priority tasks and historical dropped work. Dropped designs are not v2 requirements. The implementation notes describe the v2 design and its differences from the broader proposal.

Performance constraints

Validation and PDAs

• Pass bumps instead of using find_program_address. Avoid create_program_address where possible; consider derive_address.
• Minimize key comparisons and fail early, with cheap checks first.
• Use PDA signing only when necessary. Cache derived PDAs in state when reused.

Memory and accounts

• Avoid heap allocations; favor zero-copy and avoid copying types larger than 8 bytes.
• Avoid u128 / U256 arithmetic on hot paths. Prefer fixed-size account layouts.
• Merge accounts where possible, minimize loaded account data, and keep cold data out of hot-path accounts.
• Avoid creating or reallocating accounts during commit/finalize.
• Reuse code to limit binary size; avoid abstractions that prevent hot-path inlining.

Instructions

• Keep each commit or finalize operation self-contained in one instruction, without helper instructions or in-program retry logic.
• Minimize instruction count per operation. Avoid CPI and reliance on ComputeBudget on commit/finalize hot paths.
• Separate buffer uploads, commitment posting, verifier approvals, challenge windows, and dispute resolution remain part of the lifecycle. They do not violate the per-operation constraint; large buffers may need multiple upload instructions.

Logging and build configuration

• No logs on success. Include detailed failure logs with the instruction discriminator.
• Feature-gate debug and validation logic.