Integrate and test with application team (MS5.3)

[buddhisthead]

Description

Integrate developed Acropolis components with the selected internal application team and perform comprehensive testing in realistic application scenarios.

Intersect Milestone

MS5.3

Acceptance Criteria

Application team using Acropolis Data Node in Sundae's Scooper App in production

Expected Deliverables

• Integration test cases, results, and identified improvement areas documented
• Integration and acceptance test report confirming successful interoperability

Why

• Required for Intersect milestone.
• Demonstrates an embedded DApp on Acropolis's modular architecture

In Scope

Out of Scope

Tx Submission

Design

SundaeLabs Sample Application

External Dependencies

• SUNDAE-2146 - Implement ChainIndex trait for Scooper indexes
• SUNDAE-2122 - Persist indexer state in DB

Chain Indexer Primer

The chain indexer itself is an Acropolis module, but one with an imperative interface which we could use to set it up. The rest of the application server is Acropolis-agnostic; this module runs run in-process, and communicates with the server using mutexes or channels.

Each index has a "cursor" tracking how far it is on the chain. If we have new sets of data which we want to index, we can create a new index for them, and let that index build itself while the rest of the application chugs along. Different indexes can start at different points on-chain, so if a client introduces e.g. a new type of pool to index we only have to index from the relevant point.

Application: Sundae Scooper v2

The "scooper" is a server written by Sundae Labs and run by many operators (who are also referred to as "scoopers"). This server powers the SundaeSwap decentralized exchange DApp, It's responsible for monitoring the chain for new TXOs which define token "pools", and "orders" to be placed in those pools. It reacts to these TXOs by submitting transactions which fulfill as many of these orders as possible (called "scoops").

Sundae Labs is writing a v2 of the scooper server, since the current version is inflexible and difficult to add new pool logic into. Where v1 of the server used Ogmios to watch the chain, v2 will be using the Acropolis chain indexer to maintain custom indexes for each type of pool. These indexes will monitor and record the state of all pools, and a separate task will react to updates from the indexes by creating scoops. Our hope is that this event-based architecture will be easier to extend.

The initial scope of work is to build a server which runs in a "monitor mode": watching incoming transactions, tracking when orders are opened/closed/fulfilled, and recording which orders are and aren't eligible to be scooped (and why not). This will be useful for diagnosing user issues, and will let us validate the new architecture and logic as we build out the rest of the scooper.