# How We Built a Local Cross-Chain Simulator - Andrej Rakic | Chainlink - Channel: [ETH Belgrade Community](https://streameth.org/eth-belgrade-community) - Date: 2025-10-07 - Duration: 17:36 - Topics: People & Blogs - Watch: https://streameth.org/watch/yt-4ru692N_xrk - YouTube: https://www.youtube.com/watch?v=4ru692N_xrk ## Description How We Built a Local Cross-Chain Simulator - Andrej Rakic | Chainlink ## Transcript Our next talk is going to be related to crosschain simulators and our speaker is Andre Rakich. Um I've honestly had a chance to listen to Andre a couple of times and every time it was perfect. So u you have the stage. Andre, come here. [Applause] Okay, cool. Hello everyone. Okay, this works. Cool. So, yeah, hello everyone. My name is Andre. I work as a developer relations engineers and China collabs. Uh, you can find my Twitter handle up here and also this URL is this thing. So, in my spare time, I'm writing smart contract design patterns newsletter, which hopefully is going to be a book one day. It's about advanced design patterns in smart contract development. But that's not going to talk what I'm going to talk about today. Today I'm going to talk about how we build uh local crosschain simulator in chain link. Uh I'm not going to demo the tool for you but rather I'll speak how we approach architecture and designing of that tool. So the first thing is that you need to start with the problem. So all great ideas start with the problem that needs to be solved. And in this particular case, the problem was that development with CCIP directly on test nets is slow and occasionally painful. And I was the first one to actually experience this problem because we started when before we launched CCP, I was I had the privilege to play with it internally while was still in the development. So I already understood that pain because for me it took me like 15 minutes to send a crosschain message from Sapoleia to another test net only to realize I have a bug or a flaw in my code because I still at the time didn't know how to use uh chaining CCIP properly. So debugging was also painful because I needed to do it directly on chain. Uh obviously after we launched the the CCAP soon after we got exactly the same complaints from developers and because we are already familiar with the problem we were able to quickly uh address it and lower that time from 15 minutes to less than a second. So what I want to try to say that in best case you yourself are the target user because in general is the best if you build something you yourself need and as I said if you yourself are a target user you'll understand understand it much better than if you need to talk to developers to build a proof of concept. These are the problems I mentioned and these are the problems uh with uh building with chainingly directly on test nets and actually any other uh other solutions because you first need to deal with faucets and tokens. We know how sometimes painful is to get sepia eat for example then you need to wait for transactions then there there occasional gas spikes. So now simple action costs much more. So you again out of your funds and in the case of early CCAP we will need to wait 10 plus minutes just to sing test a single crushchain message or a token transfer only to realize that we introduce a bug or a flaw in our code and what developers want and what I wanted as a target customer was to build something locally in my own development environment. I prefer foundry you maybe prefer hardhead. But we came to a conclusion that we need to support Foundry, hardhead and remix because there's that those are the frameworks that majority of developers will cover and introducing every new framework will in uh will increase the complexity of the product and I'm going to talk about that in a minute how some stuff are extremely easy to do to be done in foundry but extremely hard in remix and you kind of need to support everything right because you need to have like a perfect product. uh then what developers want is like rapid prototyping without any extra points of friction. So we added a custom functionalities to like a function request link from faucet. So in your build local environment you have even like link tokens all the tokens everything. So you just work on your code run a test see a bug uh fix it log and all that stuff. And the most important the most important thing for this tool was to uh ability to migrate those contracts to public test networks once they are ready for public test network testing without single modification. So what you build locally with this tool you can now port back to test nets and without changing anything except for maybe config details it must work one to one. So that onetoone compatibility is hard. So now we started thinking about okay how we're going to solve this problem. The obvious maybe solution was to have a docker image to spin up couple of chain link nodes etc. But that's problematic because like again you need to support remix hardhead foundry that is a slow process uh can be unreliable docker image can I don't know can docker build can fail uh you add another prerequisite to developers to be familiar with docker or to have it installed on their machine etc. So we tried something simpler and simplicity is always good. So we thought okay what developers want to accomplish is to make sure their smart contract is CCP compatible. So when they go to test network and main networks where there is a CCIP everything's going to work. So we assume that CCP will work and we ditch the offchain components totally. So if you want to test black swan scenario when CCP is down or whatever go ahead mock it. But for this tool, we completely removed it and we said, "Okay, we're going to assume offchain components will always work. We're going to treat them as a black box and we're going to just deal with a simple solidity. So, we're going to rely on events emitted by those contracts and then our tool will do the manual switch to different networks and different transfer and that result in tests completed in 0.20 20 something seconds in foundry and little less than 1 second in hardhead because hardhead is is slower and this is the solution. Basically this is a tool I was talking about called chaining local and this is the GitHub URL where you can find it. So last year we we published it as a like crosschain simulator for CCP stuff but since then because we had initial success with this tool it involved so now it uh supports most of the other chaining products we have data support for data fits for data streams for automation um and VRF I think on a beta. So yeah, using the exactly the same approach, we then solved the problem with data streams because like again there wasn't like mock contracts with a stream etc. But what I'm trying to say is that this is the tool that uh that we created and it started literally as a proof of concept that I did after one of our u gatherings in person. Uh after that proof of concept, one month of work on this architectural designs, blah blah blah, year later, we now have a dedicated docs page. We have a chain link local swag. We have everything is like a full full product uh loved by developers. And the important part is that you need to constantly talk with developers to improve your product. So yeah, this is u another slide about what chaining local is. as I said is a dependency that allows you to build with CCAP in local blockchain environment with hardhead foundary and remix and the main architectural decision is that it abstracts the offchain part of CCAP and these are the numbers uh in speed increase we got 2,000 compared to previous state which was significant and also says highly configurable supports local chains and forks what that means is that we created a new set of smart contracts that if you want to test with specific chains like I don't know um arbitrum to optimism for in that particular block for that particular state whatever you can also do that uh with the same speed the next step now is with CCP being live Salana we need to support Salana locally and again we have uh we need to add anchor so that's another complexity that we need to introduce and also like those two does not work quite well locally because like a completely different thing. So now we again need to sit in front of whiteboard and try to figure out how we are going to uh build this thing. So what I'm trying to say is our approach is to design a product talk with developers realize what they want like what they want to click this this or this. I'm now mimicking this instead of being limited by technology instead of saying well we cannot do that because Salana is doing things this way and NVM is doing things that way and they need to spin up Docker images or whatever to support it or anchor build with this version does not work. We're gonna say okay how we're going to abstract all of that stuff from from developers. So when they use the tool is gonna is a simple of writing contract program click run test and just work seamlessly. I don't know how we're going to solve it yet. We have some ideas. It's not not ready yet. But this is the same problem we had year ago and uh that we solved for for EVM at least. So what was our approach after the proof of concept? We talked to developers. We talk with them a lot because developers are our our target customers and it was great when I was I had the problem because when I and my team we was were the initial uh target customers but since then the tool evolved. We were lucky that our community is big. We have a community of so-called developer experts. they're extremely technical individuals from our community and most of them are like quite uh willing to test this stuff with us. So I I said like do we have like volunteers who would like to walk me to who would like to walk them through the through the design through initial phases like a lot of feedback we got that never see the day of the light because like we just ditched those version in versions in the early alpha testing with our uh developer experts um because they're technical and they're also using chain link so they know u uh they know what they want essentially but the feedback back that I used as a construct was like I don't know um uh how to say that I want this thing to be faster or this was like a painful thing to do instead of like hey why don't you use uh hardhead ignition so I don't care about the underlying technology that that's not the type of feedback I'm looking for I'm looking for the type of feedback that is related to developer experience because based on developer experience and what we want to build then we're going to pick up the techn technology that's going to run under the hood because like they don't even need to care about the tech under the hood, right? They just need to to do to to be a fast thing. And it's really important to let your idea evolve as you get feedback from users. So that was initial feedback. But after we launched, there was chain link hackathon, there was it global, there was another IT global hackathon, there was Eid Global at ECC in Brussels. So we went to all of these events and we talked to developers. We saw them how they use the tool. I debug stuff with them. I literally was seeing how guy was like writing the tool etc. And I think uh one of our yeah one of our like biggest advantages was that developers were desperate for a solution because without this tool it's like 15 plus minutes for a simple cross transfer. And when users are desperate for a solution, they are willing to put with imperfect but rapidly improving product. And this allowed us to move quickly. We had something early versions. It was imperfect. It was imperfect versions but based on that feedback idea evolved and because we are a small team this is pretty much coding part was done by myself like for 95%. I was able to move forward because like it's just myself, you know, it's much much faster. So what I'm trying to say is that at after 9 months at CCC Brussels, there was like one really respected developer in the community. He won multiple prizes at it global, our own hackathons, etc. And he came to pitch us the idea and I saw from the GitHub that he used the the tool and I said, "May I ask like what was your experience with chaining local? Do you have any feedback or a feature request or whatever?" and he was and he said, "This is probably one of the best things, if not the best thing you guys built." And I was like, "Okay, cool. We made this tool perfect for one person. Now our next goal is to make the perfect tool for 100 persons and after that you get the vert uh to grow by by the word of mouth because your colleague will tell you this this is a cool tool. This is a cool product. let's use it because of this this this not because it has like other incentives. Uh I think that's pretty much it that I want to share with you guys. Yeah. Another thing is that this tool was also there was like a unis swap hook hackathon or something and there was like um there was like guys that build hooks with CCP and when we judged them I went through GitHub and every single one of them used the tool and that was like that was like my my my how to say that at that point we I knew that we did something good that we built something great and also I can tell that this uh tool is now used by uh some of our customers from banking sector like DTCC or from our uh blockchain sector like um like a hypnosis. So yeah, it's been a year but it's been like a interesting year for us. So if you want to try it uh this is the cure code and this is the link again so you can try it, use it, report bugs because as I said you need to rapidly improve your product by talking to the developers. And this pretty much sums the sums my talk. If you have any questions, uh, I'm here to to to answer them or at least to try answering them. Thank you. [Applause] >> Hey. Um, yeah, thank you. Um, chain link local is like really huge. Um, I started um, like the first time I used CCIP was at the SmartCon in 2023 and it was like, yeah, 15 minute wait times on Solio. So, yeah, it's really great. Um do you have um compatibility with functions yet? >> Uh no and that's intentional uh because for functions uh there is an mpm package with local simulations and local test nets etc etc uh functions toolkit and it has literally I think like portable ganache instance that runs under the hood that's compatible with anvil with hardhead node etc. So what I thought initially after I add supports for all chain linking services to chain link local maybe I can merge those two but then I realized that'll create like a tons of tech depth and um and I haven't heard from a from developers like a huge demand to be part of the chain link local because a lot of them were familiar with the process with working with functions toolkit and I wouldn't improve anything I would just merge the two. So for now we decided to we have it in in a backlog but I haven't started implementing it if developers like like you like come and demand that explicitly we can talk and we can add it like it's it's not a huge lift because we already have a functionality just in a different place. >> Yeah. And do you um plan to have chain link local um ready to be compatible with CR? >> Yes. >> On release because that would be that would be huge. That'd be awesome. >> I can't tell that now but yeah. Thanks. >> Yeah, you're welcome. Any more questions? Going once, going twice. If not, I'm done. Okay, cool. Thank you guys.