daml/ledger/sandbox-on-x
Robert Autenrieth 355352f2d1
DPP-650 Remove the mutating schema (#11211)
* Remove the mutating schema

changelog_begin
- [Participant] All participants now use the new append-only schema. Existing databases will
  automatically upgrade to the new schema the first time a participant/ledger is started.
changelog_end

* Fix post-commit validation test

* Remove append-only flags from CI

* Don't crash when using deprecated flag

* Increase timeout for reset service tests

* Fix typos in parameter names

* Restore removed test

* Restore removed CLI check

* Improve CLI parameter description
2021-10-21 14:40:35 +02:00
..
src KV: support contextual logging in KeyValueConsumption [KVL-1143] (#11288) 2021-10-19 20:16:37 +00:00
BUILD.bazel DPP-650 Remove the mutating schema (#11211) 2021-10-21 14:40:35 +02:00
README.md Adding first draw of sandbox-on-x concept (#9074) 2021-03-25 08:35:43 +01:00

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.