Custom DA #3237
Draft
Custom DA #3237
+2,238
−115
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Implement CustomDA preimage type (type 3) and validation flow for supporting custom data availability systems: - Add new PreimageType enum values in Go and Rust - Add ValidatePreimage opcode and implementation - Implement preimage validation caching in Machine struct - Add preliminary hash calculation for CustomDA type
- Rename dasserver package to server for clarity, moving it up one level - Rename files from dasRpcClient.go/dasRpcServer.go to rpc_client.go/rpc_server.go - Use dapserver alias when importing the server package - Update error messages to reference 'provider server' instead of 'dasserver' - This makes it clearer that the provider server is a generic component that can support both DAS (AnyTrust) and CustomDA implementations
- Update configuration option from das-server to provider-server - Change variable names from dasServer to providerServer - Update error messages to reference provider server - Align naming with the generic nature of the component
- Add CustomDA message header flag (0x41) - Add IsCustomDAMessageHeaderByte helper function - Create basic reference implementation for CustomDA - Update sequencer inbox to handle CustomDA messages
- Add UseCustomDA flag to batch poster config - Modify batchSegments to use CustomDA header flag when configured - Create CustomDA writer implementation for custom DA providers - Add reference implementation of ICustomDAValidator
CustomDA preimages that are recorded are considered valid.
It's not needed since CustomDA preimages go into their own map in the preimages map.
- Implement factory pattern for DA provider creation with mode-based configuration - Add unified daprovider.Reader/Writer interfaces supporting both DA systems - Create adapter layer for seamless AnyTrust integration - Introduce CustomDA configuration and in-memory storage implementation - Maintain full backwards compatibility with existing arbnode integration - Add --mode flag supporting "anytrust" and "customda" options - Separate DA-specific config from generic server configuration - Fix all linting issues and ensure clean build
…A provider creation This change removes all backwards compatibility from the standalone daprovider executable while preserving full functionality for the nitro node. Both now use a unified factory pattern for creating DA providers. Key Changes: - Move factory from cmd/daprovider to shared daprovider/factory package - Remove DataAvailability field and NewServer function from ServerConfig - Update standalone daprovider to require explicit --mode flag (no default) - Refactor nitro node to use factory pattern instead of legacy NewServer - Remove adapter layer - factory directly uses dasutil functions - Clean up all unused imports and legacy code paths The daprovider executable now enforces explicit mode selection while the nitro node uses the same factory pattern, creating a clean foundation for adding CustomDA support to nitro nodes in the future. Breaking change: Standalone daprovider users must now specify --mode=anytrust or --mode=customda explicitly. Nitro node users are unaffected.
…ation This change enables nitro nodes to use CustomDA mode while maintaining full backwards compatibility with existing AnyTrust configurations. The implementation uses the shared factory pattern and follows the planned configuration hierarchy. Configuration Structure: - Existing: --node.data-availability.* (AnyTrust, unchanged) - New: --node.da.mode and --node.da.customda.* (CustomDA) Key Changes: - Add DAConfig struct with Mode and CustomDA fields to arbnode.Config - Add DAConfigAddOptions function to expose --node.da.* flags - Update factory creation logic to support mode selection - Default mode is empty string, which maps to AnyTrust for backwards compatibility - Validate that appropriate .enable flag matches selected mode Usage Examples: - Legacy: --node.data-availability.enable=true (works unchanged) - CustomDA: --node.da.mode=customda --node.da.customda.enable=true - Explicit AnyTrust: --node.da.mode=anytrust --node.data-availability.enable=true This provides a clean foundation for future DA modes while ensuring zero breaking changes for existing nitro node deployments.
…d add external mode This change restructures the external DA provider configuration to follow the clean DA hierarchy established earlier. The external DA provider is now treated as a proper DA mode alongside anytrust and customda. Key Changes: - Move --node.da-provider.* to --node.da.external-provider.* - Add "external" as a supported DA mode (anytrust, customda, external) - Remove DAProvider field from Config struct, integrate into DAConfig - Update validation logic to be mode-aware - Fix system tests to use new external provider configuration Configuration Examples: - External DA: --node.da.mode=external --node.da.external-provider.enable=true - Embedded AnyTrust: --node.data-availability.enable=true (unchanged) - Embedded CustomDA: --node.da.mode=customda --node.da.customda.enable=true This creates a unified, clean DA configuration hierarchy where all DA-related settings are logically grouped under --node.da.* with clear mode selection.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.