How's Dash's decentralized platform? Working hard on it!
Check out DCG's progress in the 90th Sprint Review.
TenderDash
Goals: Same block execution
What We Planned
- Implement same-block execution in progress
- Backport remaining code from Tendermint 0.36 (master) in review
What’s Next
- First pre-release of same-block execution for integration (“alpha” quality)
- Stabilization of same-block execution (one or two sprints)
- Finalize backport of Tendermint 0.36
GroveDB
Goals: Fee continuation
What We Planned
Features
- (Tree References) -> found an easier way
- Costs in progress
- Inserts done
- Updates in review
- Deletes in progress
- Batches in review
Updates
Problem: When update a value. Either bytes will be added, stay the same amount, or bytes will be removed.
If bytes are added it’s somewhat simple: Storage flags will explain how many bytes are from each Epoch.
If bytes are removed (but the whole item isn’t): Storage flags will also explain how many bytes are from each Epoch. But the removed bytes need to be subtracted from these flags. Then for each epoch that removed bytes are removed by we need to figure out how much reserved value exists in each storage pool. We then can credit the user for that amount.
Structure
Problem: We need to update element storage flags, but costs are decided at the storage level.
Solution: Just in time storage flag updates
Drive knows: Key -> Storage Flags (structured) | Element
GroveDB knows: Key -> Element Flags (bytes) | Element
Merk knows: Key -> Value (bytes) // With that costs can be decided
Solution: Just in time storage flag updates. We pass a function from drive that can update the value based on calculated costs. This can happen twice.
What’s Next
- Costs and Worst Case Costs
- Plug in our system to RS-Drive
- Delete and Updates making things smaller need to remove costs from epochs
- These returned costs need to be given back to users
- Deletes in Batches
SDK
Goals: Rework chain synchronization process (SPV)
What We Planned
- Reworking chain synchronization process
- Adapted new logic to existing tests and workflows with platform done done
- Intermediary QA and peer review in progress
- Unit tests 90%
- Integration tests 90%
Tests covering wallet-lib, dapi-client, dash-spv packages
What’s Next
- Ensuring synchronization workflow with wallet storage
- Documentation updates
- Testing with platform on testnet
- Consensus rules fine tuning for different networks
Protocol
Goals: Release v0.23 for testnet
What We Planned
- Add withdrawal to withdrawal queues in RS Drive in progress
- Move SSL commands to monorepo and make them work with Envoy in review
- Make dashmate setup to obtain certificate in review
- Enable SSL for DAPI client in review
- BLS binding for bls signatures library in progress
What’s Next
- Continue on fee system
- Continue work on withdrawals
- Continue work on BLS Rust Bindings
- Continue work on HTTPS for DAPI
- Release Platform v0.23
Rust Port Update
The plan
- Bring all changes from v23 into the Rust DPP port in progress
- Make previous JS DPP tests work with Rust DPP binding in progress
- Integrate Rust DPP into SDK, Drive, DAPI and test suite in progress
More detailed progress report
Porting v23 changes:
Previously we’ve finished 3/17, current state is 10/20 - we’ve broke down some large tasks into smaller once, hence +3 tasks in total.Rust DPP integration:
WASM build and bindings are created, smaller data structures are integrated and tested: Identifier, Metadata, Identity.
Latest comments (0)