4b8b67a1b5
* Upgrade Scalatest to v3.2.9. Because of some coupling we also have to upgrade Scalaz to the latest v7.2 point release, v7.2.33. The Scalatest changes are quite involved because the JAR has been broken up into several smaller JARs. Because Bazel expects us to specify all dependencies and doesn't allow transitive dependencies to be used directly, this means that we need to specify the explicit Scalatest components that we use. As you can imagine, this results in quite a big set of changes. They are, however, constrained to dependency management; all the code remains the same. CHANGELOG_BEGIN CHANGELOG_END * http-json-oracle: Fix a Scalatest dependency. * ledger-api-client: Fix a Scalatest dependency. |
||
|---|---|---|
| .. | ||
| src | ||
| BUILD.bazel | ||
| 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:
- 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.
- Use it as the regression test for both functional and non-functional properties of the Ledger API server components built in the
damlrepo. We expect this implementation to satisfy the 1k CHESS+ trade/s throughput requirement. - 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.