digital-asset/daml
1
1
Fork 0
mirror of https://github.com/digital-asset/daml.git synced 2024-11-10 10:46:11 +03:00
Code Issues Projects Releases Wiki Activity
a5999abf8e
daml/ledger/sandbox-on-x
History
tudor-da 4b7391b0d5
LedgerApiTestTool prints skipped (excluded) tests (#10726) 
* Document multi-participant-only pruning test

CHANGELOG_BEGIN
CHANGELOG_END
2021-09-06 13:50:54 +02:00
..
src Command dedup: migrate kvutils to use v2 services [KVL-1049] (#10679) 2021-09-02 04:44:55 -07:00
BUILD.bazel LedgerApiTestTool prints skipped (excluded) tests (#10726) 2021-09-06 13:50:54 +02:00
README.md Adding first draw of sandbox-on-x concept (#9074) 2021-03-25 08:35:43 +01:00

README.md

Overview

Sandbox on X - Proof of Concept

This is a proof-of-concept of the sandbox-on-x architecture, which is a Daml ledger with persistency that uses the on-X architecture while being backed by an IndexDB only. This architecture is DB compatible with the sandbox-classic, while using the very same participant.state.api.v1.ReadService and .WriteService interfaces that all Daml ledger other than sandbox-classic use.

We pursue several goals with the implementation of the sandbox-on-x architecture:

  1. Use it as a drop-in-replacement of the implementation of daml-on-sql and sandbox-classic; and thereby enable a massive code cleanup due to removing the direct DB-access code used in daml-on-sql and sandbox-classic.
  2. Use it as the regression test for both functional and non-functional properties of the Ledger API server components built in the daml repo. We expect this implementation to satisfy the 1k CHESS+ trade/s throughput requirement.
  3. Lower Spider's CI times by providing them with a high-throughput single-process Daml ledger.

The proof-of-concept should have the same throughput as any other Daml ledger, and can be used for testing the throughput of Ledger API server components. Its main limitation is that it does not do conflict-checking. We plan to resolve that in the future using a two-stage approach, which first checks conflicts against a fixed ledger end and then against in-flight transactions. We expect this approach to scale to very large active contracts sets.