VOID Oracle: Better Organization of Event Emitting and Hashing

[pixelcircuits]

Currently, the oracle hashes and emits every event it sees. The concern is how does this hold up under thousands of transactions/events per second? A better approach may be to batch events into buckets of time (say 100ms). This way, only event batches get hashed and placed into a chain (more parallelizable hashing). It also makes sending event data more quantized (easier to consume and for applications to interop about).

I suggest a more traditional "blocks" construction with the following structure:

OracleBlock
Each "block" comes with a verifiable attestation. A typical block time could be something like 1-2 seconds. The oracle can skip empty blocks. It's important to note that the "EventsHashChain" is still hashed as its own chain alongside the "OracleBlocks". This makes it so the state transition function doesn't have to know about "OracleBlocks".

Header

Field	Description
parent_hash	The hash of the previous oracle "block".
height	The "height" of this current block.
event_hash_chain_head	The head hash of the parallel "EventsHashChain".

Body

Field	Description
events	A list of event blobs that occurred during this block.

EventsHashChain
A hash chain is still kept that hashes over each event. This is in addition to the block chain of "OracleBlocks". The advantage of keeping a chain that hashes each event is that it means the Oracle can free all memory of an event once it's been seen and processed (including broadcasting to a cache outside of the secure element). In other words, the "OracleBlocks" can be built in realtime with no final post processing required. This coincidentally also makes it possible to run an Oracle inside a blockchain for maximum security (at the cost of only being able to observe a subset of on-chain events). The hashing structure for the chain should be as follows.

Field	Type	Description
previous_hash	32 bytes	The previous hash head for the chain.
event_data_hash	32 bytes	The hash of the events blob of data (event data blobs can be hashed in parallel).

---

To summarize, the oracle would now emit "OracleBlocks" with attestations at a configured interval (for example, every 1s).

note: if lower latency is desired, the oracle can optionally publish "pre-confirmations" in the same style as flashblocks. This essentially works by having the oracle publish partially complete "OracleBlocks" as the events are streaming in for it. For example, maybe you have 200ms "flashOracleBlocks" but true "OracleBlocks" with TEE attestations only come every 2s. flashOracleBlocks" can be signed over with simple signatures (ex. ECDSA), which are susceptible to side channel attacks, but don't need as strong of security guarantees since they are short lived (superseded by an eventual full TEE attestation).

note: this removes most of the need for time based events or the optional include_timestamps param for the EVM stream as timing needs are set per app in the oracle setup now (in the context of app re-sequencing)

[freesig]

The EventsHashChain doesn't make sense to me. The height should be the height of the event not the block. Also you can't include the hash of the current event as that has to be computed by the checker so it should only be the parent hash and the event height.

I think the flash block is YAGNI for now

[pixelcircuits]

I agree on the flashblocks support not being super needed from the oracle. The oracle should be able to handle 200ms blocks just fine. I can confirm this is at least the case for SGX which takes about 50ms for an attestation, but we'll need to sanity check TDX, AWS Nitro and other TEE solutions.

"height" can possibly be removed from the events hash, but it costs nothing to have it there (hashing 64 bytes and 96 bytes takes the same amount of compute in sha256). It mainly removes the need for a special block delineation event, which is harder to replicate if we want the oracle to run on a blockchain (non-TEE VOID).

Hashing the data of an event, and then using that hash in the "EventsHashChain" adds parallelism to the hashing required by the oracle. It also gives us a solid way to measure the hashing TPS upper limit (assuming infinite parallelism). The sequential nature of the EventsHashChain is probably the biggest attack surface for spam attacks.