Dash Platform Sprint 90 Review – Summary
Tags: web3, opensource, blockchain, programming
Published: 2022-09-07 18:22:49

How's Dash's decentralized platform? Working hard on it!
Check out DCG's progress in the 90th Sprint Review. 

{% embed https://www.youtube.com/watch?v=3yrnk3RE5aY&t=69s %}

## 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.