When a Chain Shuts Down: Keeping On-Chain History Alive

Transcript

[music] Hello everyone. I'm really glad to be here today. Um so today I'm going to talk about uh keeping on story alive uh when the chain shuts down. Um but first of all let me ask you a question. Who does remember MSN Messenger? Yeah. for for the youngest it was the main way to chat in the years 2000s and basically in 2013 Microsoft shut it down migrated some part of the data to Skype but some were lost and actually one year ago Skype also was shut down and they

migrated to teams that led to another question which of today's blockchain will be the MSN messenger of 2035 and to understand a little bit why it's important uh to be able to answer this question and to be prepared to to to the answer. Let me uh uh talk uh present you a little bit I give you a little bit of context about what we are doing at Spyo. So, Spyo, it's a tokenized fund supervised in the European Union and basically we are issuing uh token on several blockchain uh basically five EVM blockchain stacknet, stellar and solana and being regulated it means being able

to keep operation running even if a blockchain is dying or shutting down. So continuity means having for every blockchain an exit plan. What does it mean leaving a blockchain? Uh it's a two-phase problem. So basically you need to migrate two things. On one side you need to migrate the states and on the other side you need to migrate the history. So for the state basically it's the balance of the user the the balance on each token. Uh so that's kind of pretty straightforward. uh e either the blockchain is still active so you can uh still bridge the gun from the the dying blockchain to the to the to a target new

blockchain or if it's not up anymore you can just remint them uh it can be operationally tricky but uh it's a nonplaybook on the other side the history it's h it's quite new uh by history I mean all the event that had occurred on the blockchain uh all the mint event, transfer event, burn event and there is no standard way to store them on on another blockchain. So why should we care? Uh basically um I see two reasons for that. The first one is a philosophical one. Uh history it's written on chain if [snorts] a blockchain is not here anymore. Uh either you keep you you keep it offchain but it's not really in the web three

philosophy or you need to to keep it to still have it onchain. And the other one which is uh even truer for for Spyo and other regulated business is that uh you have regulation obligation such as being auditable for years uh and so having all the the history on chain uh helps a lot in this matter. So our solution it's uh a standard proposal to uh archive events on uh on the blockchain. So basically it's a standard interface uh that you that that you can see on the screen uh which define how we should uh emit uh remit an event on another blockchain. So it's an

event called uh event archived which store all the information that you need to uh trace the origin of of of an event. So you have the source chain ID, the source transaction ash, the source address, the log index and the row payload. So you can parse it the same way it it was pared on the on the other uh blockchain. There's also a small version field uh for operational reason because uh bugs happens uh when you when you deal with blockchain. So you need to be able to amend it uh if if uh you archived an event badly.

It's a standardization uh and a proc proposal and basically it's all about the standard of the interface the writing pass is uh and especially the permission is left to the to to the implementation. So basically what does it like uh and how we we use it uh in spyo the flow it's quite straightforward actually you have a dying uh blockchain for example uh do chain and uh you need to uh relaunch the indexer on all the on all the the blockchain to uh get all the event and replace them inside uh to send them to the archver my contract which replay the event inside the new target

network. Um, and then you can reindex the target network and the archival contract to get back this event whenever you want. So that's all for today for for myself and uh if you have any question I will be glad to answer them. Thank you very much. >> Amazing. Thank you Nicholas. Any questions in the audience? If so, please raise your hand. Yeah. Okay. And then look out for a box.

Okay. Over here, the blue shirt. Yeah. >> Have you run this for any dead chains already? >> Um not yet. Not yet. So uh because there have not been so many dead chains uh recently. [snorts] Uh but the idea is to uh it's to be completely prepared to to do it and to do it proactively. Uh archiving event. You can archived uh on one or several blockchain actually and uh as archiving 10 years of activity on the blockchain can be quite long, it's better to do it along the way.

>> We got another question over here. I speaking all right so uh uh have you um done some performance uh ran some performance numbers on this because this might be a huge activity. So uh how expensive could it be right writing a if say we want to write a dead chain to some L1 let's take Ethereum then that would be quite expensive and uh how would that uh bring that return of investment of uh having the data >> um yeah basically it will be more expensive on L1 than L2. So I will advise to do it on cheap L2 like arbitrum or or the strongest one. Uh but

basically really the standard it's really only about emitting an event. So it's the cheapest things that you can uh that you can do on uh on the the L1. So it's uh it should not be it depends on the uh on the on the the protocol the company uh on your onchain infrastructure but uh and so it depend of on the scale obviously but it should not be too too big. >> Okay, one more question over here. Look out for the box.

>> Yeah, nice catch. >> Yeah. Hello. Uh so how do you handle the version conflicts by the way when it is transfer from migrating from one chain to another? >> Um basically the the version the the version field it's it's incremental. It's a it's a strictly incremental uh is deal it's dealt by the the contract itself. So uh it's not done it's not uh it's not given by uh by the the user uh the the the operational service that called the >> I mean are you mentioning any specific field in the metadata in the ERC standard by the way >> you mean uh this one the version

or >> yeah yes oh yes version >> yeah uh oh sorry um yeah the the version yeah the version is This field is strictly incremental. So each each time you archive an event either it's the first uh it's the first time so it's version it's version one or if uh if you rearchive the same event with the same the same key key of an event it's a chain ID uh log index uh and block number and that's uh that trigger a new version on top of it. a new event that that a new event emitted.

>> Understood. Uh as per your perspective, uh what is the smartest way to dduplicate these events? >> Um the really it's it's really just it's a it's quite straightforward actually. It's really a matter of uh of reading the the the the event history and [snorts] uh gathering all the event archived uh event and then uh doing a reconciliation on uh on the the version number. >> Yeah. Sorry.

>> Uh that's fine. Uh but actually we have we know hot, warm, cold stoages, right? So are we maintaining those things in the archive? Um, sorry. I I think I did not for example I suggest we maybe take it off the stage afterwards. Sounds like a great discussion. [music]