The SEDA Engineering team continues the final touches to the v0.4 devnet upgrade in preparation for a complete mainnet upgrade to v1.0 before the end of the year. The v0.4 is the most significant update to devnet and requires multiple sprints for completion. The recent two-week dev sprint saw progress across seven vital components of SEDA’s architecture.
Batching & Tallying Module Updates
Data requests can now be batched onchain. Batching collects multiple data results and groups them into a ‘batch’ that is pushed onchain and can be ‘unpacked’ by consumers to access the desired results. Batching allows for more data result information to be added to a single block, significantly improving the efficiency of the network. To learn more, see the September's Engineering update here.
The current focus for engineers regarding batching is to deploy a module that allows validators to sign and vote on complete batches that uphold the integrity of data, ensuring no data is manipulated onchain. This upgrade, once complete, will ensure solvers can use batch data to relay results to the consumer network.
Overlay Network Upgrades
The Overlay Network is undergoing optimization, with the engineering team decreasing the current CPU impact to improve network proficiency. In preparation for the mainnet core audits, the team is battle-testing the network to identify bugs and bring it up to its optimal function.
The Solver Network
The team working on the Solver Network’s primary focus is deploying a specialized solver SDK for app-specific solver needs.
An Example Of The Specialized Solver
The SEDA Prover Contract does not need to keep track of incentives simply because the specialized solver forwards batches and data results by themselves. Imagine Protocol XYZ that needs some data results in CHAIN B. They could send the data requests by themselves directly to the SEDA network or to CHAIN A (because it is much cheaper), and then have a specialized solver that will post ONLY THEIR data results to CHAIN B. This allows a much more cost-effective approach for protocols in specialized situations.
The Simple Solver is in its final stages before deployment. It focuses on relaying requests and results between consumers and SEDA. As it stands, the simple solver is focused on relaying between EVM networks only, with a later upgrade connecting other ecosystems.
EVM Contracts
Two types of provers are being worked on for EVM contracts
1 )Secp256k1 Batch Prover
Allows batches to be updated ONLY when signed by validators.
2) Data Result Prover
Ensures data results are only valid if they are included within a batch
These upgrades will allow for proving that data has come from the SEDA Chain with cryptographic proofs — maintaining data integrity.
Explorer Design System
The SEDA Explorer is set to undergo a complete redesign, focusing on improved UI/UX for developers. Front-end engineers are currently focusing on index Oracle programs being deployed onto the SEDA network. This will allow the exploration of specific programs on the network. Additionally, users will be able to filter data requests based on the Oracle program used, greatly improving user experience.
DevOps
The DevOps team is working with our infrastructure partner [REDACTED] to automate the integration process of new chains, focusing on modular design principles and role-based access.
Chain Contracts
SEDA chain contracts have been upgraded to include timeouts for Commit and Reveals of data results. Data timeouts are set to 10 blocks as a standard but can be updated via a governance vote from the SEDA community.
