Content
@
0 reply
0 recast
0 reaction
Hylé
@hyle-org
We all want to execute offchain and verify onchain. But have you thought about transaction concurrency? Here's how we're solving it on Hylé, one delayed proof at a time! Our blog post: https://blog.hyle.eu/opinion/an-introduction-to-delayed-proving/ Let's take an ERC20 running as a provable app. Bob wants to send 2 tokens to Alice. Execution happens offchain, and so does proof generation. What the blockchain receives is the new state of the ERC20 application and the proof of the state transition - and verifies it. But what happens if Bob and Alice both transact at the same time? Two proofs created from the same state will conflict: the 2nd proof should be based on the final state of the 1st proof… But this information is not available yet! 2nd tx will have to be proved again.
5 replies
0 recast
2 reactions
Hylé
@hyle-org
Hylé's solution is to split the sequencing entirely from the settlement. We call it "Delayed Proving". A transaction now has: 🔸 Blob-transaction: The statement (e.g., Bob sends 2 tokens). 🔸 Proof-transaction: The proof attesting to the state transition, verified on Hylé. Hylé sequences the blob-transaction, then settles once the proof is submitted. Why that's great: a) Removes proof generation times as a bottleneck for provable applications b) Users can offload proof generation to specialized players like prover markets c) Super fast soft finality by only sequencing blobs before proving Read the blog post! https://blog.hyle.eu/opinion/an-introduction-to-delayed-proving/
0 reply
0 recast
0 reaction
Mikimoto
@mikimoto
support
0 reply
0 recast
0 reaction
elreinoinfantil
@elreinoinfantil
support
0 reply
0 recast
0 reaction
Blancpain
@blancpain
support
0 reply
0 recast
0 reaction
kondzilla
@kondzilla
support
0 reply
0 recast
0 reaction
