[Prototype/Spike] soroban-rpc: Design Data Backend

[paulbellamy]

epic - stellar/stellar-rpc#43

To serve contract events to clients, we need to get the events from somewhere. The events are in the ledger close metas. But where should we get those from?

Assumption: Let's ignore historical replay for now (but consider how we would do it in future).

There are a few potential options here to evaluate:

• Implement Zenith Data Backend flow: TX Meta -> Index by Contract: AccountID, ingest, serve stream
  • Paul: Probably the one we want to go for, but needs proving/testing.
• Use the core buckets, and grab the current state directly from core
  • Paul: Definitely a terrible idea. But technically possible.
• Or use custom ingestion
  • Paul: is this just captive core? I'm not sure I fully understand the suggestion here. The upside here, is that we don't need persistence, so it could just ingest the ledgers, and emit events. Is there really much to test here?

Understand:

• Ease of use (deployment/runtime reqs/etc)
• Performance
• Running cost
• Any gotcha’s / tradeoff's

Desired outcome is a decision about which approach we want to take.

[12/16/22] - Soroban RPC design discussion today ended with consensus from group to take Option 0.5 first, as part of that design it proposes soroban rpc will use captive core and run it's own custom ingestion against that which would then be persisted into the data backend decided here.

Timebox to ?

[sreuland]

for context, a couple documents have had some good discussion take place in this area:

https://docs.google.com/document/d/1NYo6vg3pxa-BDd75sJQ3yPNHl5S7ZlsqsosRqaYY9jg/edit#

https://docs.google.com/document/d/1vBBL10O1INjvekeENledAjjGje8FFRPIMQc1gf7kZ9M/edit?pli=1#heading=h.zbqye2p3y6ut

[sreuland]

maybe consider mq brokers, some discussion here on hot vs cold subscriptions for durable messages - https://stellarorg.atlassian.net/wiki/spaces/PLAT/pages/4434690049/soroban-rpc%3A+grpc+and+json-rpc+comparison?focusedCommentId=4447240228

some options on how Zenith may look if it published to mq broker as on alternate store rather than s3/f/s, then soroban rpc could potentially subscribe to mq topics and use offsets in the subscription to achieve replay scenarios or forward-only type streams, depends on the broker used:

https://stellarorg.atlassian.net/wiki/spaces/HOR/pages/4340678664/Zenith

[tamirms]

https://docs.google.com/document/d/1F60xINIbfKrdnGeBBxygeHU3ZlgthRJw8DLXaYDakl0/edit?usp=sharing analyzes the different database options for storing events. SQLite appears to be the most promising option. We can ingest the events from TX Meta (either coming from captive core or a TX Meta stored on s3 via ledger exporter) into a SQLite database.

[tamirms]

One important gotcah regarding SQLite:

simulateTransaction will require soroban-rpc to look up ledger entries while executing a smart contract invocation. These look-ups need to be consistent to a single ledger sequence. This can be implemented using repeatable read transactions in Postgres or read-only transactions in BadgerDB. However, SQLite does not support repeatable read transactions so we will need to introduce a read-write lock to ensure that ingestion cannot operate simultaneously with simulateTransaction requests.

[sreuland]

@tamirms , I updated description/scope, mentioned the agreement that was reached to follow the 0.5 RPC design option, which would be a part of this back-end context.

[sreuland]

@tamirms , is this complete, seems like it's wrapped up as work has started on #4682, if so, please move this to done and set CompletedSprint, thx!

[mollykarcher]

Closing this in favor of #4682 and #4731