Security & Ceremony ft. Range

Space Summary

The Twitter Space Security & Ceremony ft. Range hosted by union_build. The Security & Ceremony Twitter space featuring Range dives deep into the innovative interoperability protocol, Union, highlighting its pivotal role in connecting diverse blockchain ecosystems seamlessly. The discussion emphasizes Union's hyper-efficiency, scalability, and future impact on blockchain connectivity. Range provides valuable insights on the protocol's benefits, envisioning a collaborative and innovative future for Union in the blockchain space. Union emerges as a key player revolutionizing infrastructure in the blockchain industry, setting new standards for efficiency, security, and network integration.

For more spaces, visit the Infrastructure page.

Space Statistics

For more stats visit the full Live report

Questions

Q: What makes Union stand out among other interoperability protocols?
A: Union distinguishes itself with its hyper-efficient approach and seamless cross-chain functionality.

Q: How does Union contribute to enhancing blockchain scalability?
A: Union's focus on scalability ensures faster transactions and improved network efficiency.

Q: What role does Union play in connecting different blockchain ecosystems?
A: Union acts as a bridge, enabling smooth interactions between diverse blockchain networks.

Q: What are the key benefits of utilizing Union for blockchain interoperability?
A: Union offers increased efficiency, lower transaction costs, and improved user experience.

Q: How does Range envision the future growth of Union in the blockchain space?
A: Range foresees Union driving innovation, fostering collaboration, and expanding blockchain capabilities.

Q: In what ways does Union streamline transactions across various blockchains and rollups?
A: Union simplifies cross-chain transactions, leading to enhanced interoperability and network integration.

Q: Why is Union considered integral for the evolution of blockchain technologies?
A: Union's ability to connect disparate blockchain ecosystems paves the way for enhanced functionality and widespread adoption.

Q: What challenges does Union aim to address in the current blockchain interoperability landscape?
A: Union tackles issues of compatibility, scalability, and efficiency to facilitate seamless blockchain interactions.

Q: How does Union contribute to the overall efficiency and security of blockchain transactions?
A: Union's protocol enhances transaction speed, security, and reliability, ensuring a streamlined blockchain experience.

Q: What opportunities does Union create for developers and users within the blockchain space?
A: Union provides developers and users with new possibilities for cross-chain functionality, collaboration, and innovation.

Highlights

Time: 00:12:45
Union's Role in Blockchain Interoperability Exploring how Union bridges the gap between different blockchain networks.

Time: 00:28:19
Scalability and Efficiency with Union Understanding how Union's approach enhances scalability and transaction efficiency.

Time: 00:39:55
Future of Interoperability: Insights from Range Range discusses the future implications and growth of Union in the blockchain space.

Time: 00:47:32
Benefits of Union for Blockchain Ecosystems Highlighting the advantages of utilizing Union for seamless blockchain connectivity.

Time: 01:02:14
Union's Impact on Network Integration Examining how Union contributes to the integration and connectivity of diverse blockchain ecosystems.

Time: 01:18:06
Range's Vision for Union's Evolution Insights from Range on the evolutionary path and potential of Union in the blockchain interoperability landscape.

Time: 01:35:42
Security & Ceremony: A Deep Dive into Union A detailed discussion on Union's security features and the ceremonial aspect of blockchain integration.

Time: 01:49:28
Union's Hyper-Efficient Protocol Analyzing the efficiency and innovative protocols of Union in revolutionizing blockchain interoperability.

Time: 02:05:11
The Union Ecosystem: Connecting All Networks Exploring how Union acts as a unifying force across diverse blockchain ecosystems.

Time: 02:17:59
Union's Mission for Seamless Blockchain Transactions Understanding Union's mission to streamline transactions and enhance network functionality.

Key Takeaways

• Union is a pioneering interoperability protocol enhancing cross-chain transactions.
• The Security & Ceremony space delves into the significance of Union for blockchain connectivity.
• Scalability and efficiency are focal points in Union's approach to interoperability.
• The discussion emphasizes Union's role in connecting diverse blockchain ecosystems seamlessly.
• Range shares insights on the innovative features and benefits of Union in the interoperability landscape.
• Union aims to streamline blockchain interactions and enhance overall ecosystem functionality.
• Participants gain a deep understanding of Union's mission to revolutionize blockchain interoperability.
• The Security & Ceremony space highlights the importance of Union in the blockchain industry's evolution.
• Range provides valuable perspectives on the future implications of Union for blockchain networks.
• Interoperability protocols like Union are crucial for the seamless integration of blockchain technologies.

Behind the Mic

Introduction and Greetings

Thorndye it. ZK GM. Can you guys hear me? Hello, sir, how are you doing? Hey, Carlo. All good, thanks. Thanks for having me here. Yeah, no worries. Excited to chat a bit about the ceremony and some security related things. And I see we also have Cor and Robert from the union team. So if we want, we can also expand it a bit if we want to make this more of a denser session. Yeah, I love that. I mean, I think the ceremony that you guys are doing, I would love to learn much more about it and also talk all things, of course, bridge and interoperability security. I think that we have a lot to talk about. So happy to make this as dynamic and as you guys want.

Introductions of Karel and Andres

Yeah, sounds good. So for the listeners brief intro about me, I'm Karel, CEO of union, developer for, I know, like almost a decade now. Previously CTO at Composable. So you can ask me any technical questions you want as well. And I'm here with Andres from Range security. Yeah, some words about me as well. So I am Andres Monti, co founder and CEO at Range Security. Yes. You know, like, my background is actually in astrophysics, but I've been working in the industry for about six years now. Started as a research engineer focusing on consensus algorithms in theorem ecosystem. So this was like, you know, PBSD IvsT 2.0, things like that, when Ethereum was still pow and all these sort of casper conversations. And that led me to, of course, tendermint. That led me to focus on the cosmos ecosystem, which is what I've been focusing for the last three and a half years. Before starting range, I was a lead security auditor at ox security, doing mostly Cosmos SDK and Cosmo WAsm audits.

Experience and Focus of Range

Also spent time doing like bug bounties and six figures, more than six figures in bug bounties and started range about two years ago to solve what we think is the key bottleneck and one of the biggest problems in the industry, which is the security problem. And yeah, like a bit of about range for the ones that don't know range. So we are the blockchain security intelligence platform with a lot of focus on sort of like post deployment security. We can go a bit deeper on that. What is that later? And we focus a lot as well in cross chain monitoring and of course like the cosmos ecosystem, IDC and now as well, Solana and SVM. Yeah. Awesome. So you are basically to blame for the fact that Ethereum doesn't have single slot finality and that we need to deal with that you were there during the time when they discussed what to do. I wish, I wish that back then I was just an intern.

Discussion on Consensus Algorithms

In a way, I'm still, I am an intern, but, yeah, like, I think it was like a super interesting time because, like the, you know, like most of the discussions at that time, like we're like about like technical things. And I feel maybe it's sort of like this good old days feeling, but like people were very passionate about like these sort of consensus algorithm discussions and. Yeah, like, I am, though, not like the cause that we don't have like, single finality in Ethereum, but I'm sure that you guys are going to find ways to circumvent that constraint. Yeah. So for people listening here, like, the type of consensus that the chain uses is very close to union's heart because that is actually what we write like a lite client for what we encompass in a contract and what we track.

Finalization of Blockchain Transactions

So in our case, we usually dive very deeply in the white papers and the note implementations for different chains to see how does the chain actually finalize. Finalization is the process by which basically all the validators agree to never revert a block again. So in the case for cosmos chains, for example, that is always immediately. So when a block is produced, all validators have voted on it. In the case of Ethereum, that happens periodically on top of my head, every 64 blocks, although it's a bit more complex with Ethereum and the exact guarantees you get for the different epochs. And this differs for, like, many different chains, what that kind of algorithm is for when it finalizes, and we can truly trust that the block will always be there.

Understanding Block Finalization

You see this probably when you use centralized exchanges because it will show you like, number of confirmations, and that's basically waiting for a block to be finalized. And so we do the same deep down the protocol, and that's kind of the fundamental security guarantee that union has on if the funds will not go to another account, like if they really are in the union vault or if they end up somewhere else. That's why we need to wait on it. So, yeah, I think maybe good to start off with a kind of introduction of what range exactly does and how we're collaborating on this, and then afterwards we'll dive a bit deeper into the ceremony.

Range's Functionality and Services

Yeah, of course. And I think, you know, like, as we started the conversation talking about ethereum upgrades, I think like another upgrade that can be like, quite interesting to discuss was like the, you know, one of the precedent ceremonies that happened in this industry like the KCG, but before that just described what range is about. So as I said before, we are the blockchain security intelligence platform. And what does this really mean? So range is actually a platform with different verticals. We focus a lot on real time security and alerting. So if we think about the security lifecycle in crypto, we make a clear difference into pre deployment security.

Security Lifecycle: Pre and Post Deployment

And this is things like audits, formal verification and things like that, and then post deployment security. So when your protocol is live, what can we do to make the protocol more safe, or at least be able to respond to incidents, operational or security in a faster way? Range as well has a bunch of tools targeting intelligence and investigation tools. So that's another part of the security lifecycle, which is when you want to really understand what's going on in the blockchain you use or actually in the bridges you use. As we know now, the reality is that crypto is very multichain like. Cross chain activity is ever increasing. And of course, with projects like union, this trend is going to accelerate.

Cross Chain Activity Monitoring

So we actually make sense of flows of addresses and transactions that happen between multiple chains. We do this through some visualization tools like range trail that can enable teams from builder teams, but also auditors or investigators actually understand and track wallets. This is very relevant when something bad occurs, but also before just trying to understand what's going on and what type of wallets are interacting with your programs. We have as well what we call an advanced cross chain block explorer, and we are the team behind the IBC and USDC explorers. This is, again, tools that we build mostly for the community and for developers to actually help them monitor transactions across chains.

Preventing Hacks and Enhancing Security

And then we do as well, things that go with the objective to actually prevent hacks. One of the major initiatives on that direction is our work with IBC rate limits, and that's projects that we've been doing in collaboration with teams like osmosis or neutron. And here the key is we build help design on chain safety programs and business logic that can cap the downside if something bad occurs. And as we can see, as we all know here, this gets very relevant for bridges, which historically have been the biggest exploits in crypto. And basically with this IBC rate limits, you kind of contain the blast radius and it's in the same way as putting you like your signal, right?

Impact of IBC Rate Limits

So even if something bad happens, like the, let's say, the injuries in the protocol or like, the amount that is at risk is greatly reduced. So in a nutshell, we do a lot of things in the sort of like security risk mitigation and intelligence realm, and with a lot of focus on the cosmos ecosystem and. And as well on cross chain and interoperability activity. Yeah. Awesome. And we need to shed some light for people listening in. Union is working with range, so we're basically leveraging them as well. For cross chain Explorer, although we provide our own, I think it's good to have multiple implementations.

Collaboration and Implementations

And I think unless the implementation you guys have is like the nicest power user implementation with all the bells and whistles for researchers and such. With ours, it's more geared towards end users as well as we provide the GraphQL API that developers can integrate in their own apps. So you don't need to rely on multiple indexing services. If you write a cross chain app, you can just use unions API and you get the full transfer and transaction traces of everything that is ongoing in the system. Yeah, and we are super excited to be collaborating with you guys.

Interoperability Protocols

As mentioned before, I think interoperability protocols and union in particular, can be like the nexus of many different blockchains and networks. And these make them sort of like systemic in a good way, because there is like a very strong network effect, but also they become very relevant for the security not just of the bridges themselves, but also the whole ecosystem. And I think it is super exciting, given the many routes that union is going to be opening up between different ecosystems. Just be able to work with you guys and go to the places that you are going to be opening the routes and just making sense of all these crossing volumes and trying to make all these cross chain activity more safe and secure and also available for users and developers to actually understand it.

Future Trends in Cross Chain Activity

Yeah, at least the way I see it, we would see a lot of people talk about application specific sequencing at the moment, which, to be honest, is just another form of app chains or app specific roll ups. But the trend that we just see is way more applications are going to their own state machine, and the state machine really is just a blockchain. So that means that fundamentally, even though, don't worry, we don't expect end users to be bridging themselves all the time, but under the hood, a lot of applications will be bridging in between each other fully, automatically.

The Future of Crypto and Interoperability

And so I kind of think the world we're heading into with the next bull markets the next few cycles is that crypto is going to resemble treadfire much more, with massive amounts being cleared and settled in between banks every day. The same as what we're seeing between blockchains and right now, to be honest, the volumes, they've actually risen a lot. It's unthinkable that nowadays we're bridging as much daily as the market cap of many top ten coins about eight years ago. But I think it's going to go up from like a couple of billion a month to trillions in total, being cleared and settled all the time.

Role of Range in Security

So parties like range are indispensable for keeping that secure and keeping track of these asset flows. And for me at least, like, I want union just to play a role in making it super easy for anyone to tap into this. Yeah, I mean, 100%. And I totally agree with sort of like this vision that you have and I guess the sort of like ideal that many teams are working in the space and something that is being spoken about a lot, which is like this chain abstraction idea, right.

Chain Abstraction and User Experience

Or even like intent and things like that, which, you know, I think the end goal is that hopefully the users are going to be forgetting slowly all these sort of cross chain words and things like that. But the thing is that under the hood, this is ever increasing for the reason that you said, if applications are going to their own state machines, even if projects are able to extract this from the users, there's still going to be a lot of cross chain activity or actions and intents between addresses and entities from different environments or state machines. So, yeah, the trend is, I think, accelerating.

Conclusion and Future Perspectives

And it's pretty clear that in the next couple of years, this is only going to be increasing. Yeah, 100%. And it's sort of like one of the reasons that we originally founded union was were a group of developers ourselves, thinking, what are we going to build next? And in the end, what you end up with is if you want to build like a really good product, you're going to end up with an app chain yourself. The mode that, like hyper liquid or Dydx before has oversmart contracts is so big that if you want to build like a really good product that's really good, you actually kind of have to go in that direction.

The Journey of Bridge Support

Like, getting Bridge support is like a six month journey. So with union and kind of a cluster of companies around us, that's what we originally sought to solve, to make that not a six month journey, which is something that you kind of finish in the first day that any builder has access to. I think that's the big unlock for smart contracts to make the migration to app change or app roll ups, and then with chain abstraction and account abstraction making this palatable for the user as well.

Communication of Chains

So it kind of seems like we have just a big swarm of chains that communicate like one same experience as Solana monolithic chain has between all of its apps. Yeah, I mean, if you think about it, like, I think theoretically, like, just having your own sort of like app chain or app roll up has made a lot of sense for already quite some time. But the reality is that developers until now had constraints. One of the key constraints is of course the paying for security type of inflating rewards, paying for validators, which this is of course being solved by all these roll up focus projects.

Liquidity Issues

And the other is liquidity, because like if you sort of like are kind of separated to the world, like you need to bootstrap all that. But that second piece, which is very important, is being solved by projects like you guys, like union. So I think, like, if all these boxes get checked, like, the arguments to not launch in your own sort of like state machine gets, keep getting like smaller and smaller until it's going to be just a no brainer for everything to just be their own chain roll up, whatever we call them.

Developers' Perspectives

Yeah, I think indeed, like three years ago maybe as a builder, indeed, most significant argument would be like, does your app require like a distributed peer to peer network of 100 nodes plus RPC nodes to operate? Right. You saw a bunch of app chains in the cosmos ecosystem where even though the application is really good and they have a decent amount of users, it isn't big enough to warrant such an infrastructure investment. And then you just have to pay such massive emissions to your validators, then the token is down.

New Era in Development

Only I think we've actually reached the era where we have solved this. I don't think we've solved it with like restaking and buying security from other parties. I actually think we've solved it with roll up technology and especially being able to do ZK rollups. That to me is like the best solution to not need to pay a part of your revenue to an exogenous security set. People want to have their rewards go to their own token holders, not to ETH holders, for example, while at the same time like having the same security guarantee as a full chain has.

Infrastructure Simplicity

And ideally like not needing to manage that big peer to peer network. Right? Like having just one big roll up nodes on the machine is much easier infra for startup to run and they can decentralize it down the line by having multiple doing a decentralized sequence or something for failover protection. But that works even if you only have like four to six sequencers. Right. Then you are nicely distributed, but you're not paying 400 validators.

Improvements in Roll Ups

Yeah, I mean, I think that, and I think it's been quite interesting to see sort of like in the last couple of years where it did seem that, you know, like for roll ups, like everyone thought that the crypto economic approaches were going to be faster to market and be sort of like a transition period until CK technology was ready for primetime and just be able to replace this as the sort of like end game solution. But it seems that the opposite has been true.

Advancements in Zero-Knowledge Technology

I think surprisingly, at least for many people in the industry like myself, how teams and CK technology has been able to advance that fast. And then on the other hand, more crypto economic solutions and sort of like optimistic type of solutions have seemed to be harder to get to production level with photos and everything. So yeah, it's quite interesting development and it seems that also like that's the kind of a thought process and a design decision that you guys did while doing union, which is kind of very in contrast to other of the interoperability solutions which lean much more on the sort of crypto economic warranties against the CK tech.

Crypto Economic Solutions

Yeah, because I think the crypto economic solutions are basically optimistic with fraud proofs and making that open, decentralized, like allow anyone to dispute and make those systems work. We've kind of seen them go to production and then being taken out of production again. I don't think we've ever seen them be successfully executed or they go through a full test run and show that they could actually work on Mainnet as well as the mean life for a significant amount of time.

Recommendation for Builders

And now you're seeing GK being fast enough to actually migrate these optimistic roll ups to ZkDe. So that would be my recommendation for any builders listening here in this chat. Like, if you're thinking I'm going to do my own roll up, do I go for an optimistic stack? Optimistic seems to be faster to get off the ground initially, but I don't actually think it's that much faster because you need to run different watcher nodes that could dispute.

Testing the Protocols

You need to periodically, basically fake a dispute on your testnet to make sure that whole protocol still works end to end. Kind of play the disputing game and resolve to the correct settlement while with the ZK rollup. Sure, you need to get like one server with the GPU to be able to produce proofs. Or nowadays, like you can just use proving services like Bonsai or Synctis running or Sindri to have it be performed for you and your off the rails.

Finalization and Security

You finalize immediately. You always know that you're fully secure and there's no need for all these watcher nodes, disputing nodes, stakes being put down, et cetera. So I much prefer that model. Overall, it's easier for union to work with too, because for optimistic roll ups, we actually see higher bridge latencies. Those of you who are on our testnet probably noticed that going into arbitram is fast, but out of arbitram takes a while.

Challenges with Optimistic Solutions

That's because we need to wait for arbitram soft finality to occur. If arbitrage was just a full ZK roll up, we would be basically able to bridge out of it much faster. So scroll, for example, is a roll up we prefer working with at the moment, from a tech perspective, nothing on the team specifically here because it's a ZK rollup. And at the moment, I think they settle on mainnet like every two minutes, they're looking to settle every 1 minute.

User Experience in Protocols

And that really involves the UXMR sides. Makes the whole protocol much easier to build, much easier to track. Kind of low key. My dream is for all of these UK road loops, you just settle every eth block or every other block. That's how we get like the ultra good ux, where we see like bridge transfers being completed within a single block time.

Critical Steps in Zero Knowledge Proving

Yeah, I mean, I guess that the, I guess it's not the caveat, but only thing that, like these CK tech systems, like need to do. And that's, I guess that the protagonist of the week and the month is sort of like the trusted ceremony itself. Right? So, yeah, I mean, I love to dig a bit deeper there just because how timely and also because what I've been seeing from, you know, like from your twitter, maybe you can share more information there is that, like it might be like one of, I'm not sure if the largest, but at least one of the largest.

Study of Previous Trusted Ceremonies

And, you know, like, I love to know, like studying like previous trusted ceremonies, like from the very ogs, like the CK cash, and actually like the most recent ones, like the dank sharding one from Ethereum. Like, how have you guys thought about this sort of like zero to one critical step for union and the whole like zero knowledge proving system?

Characteristics of the Ceremony

Yeah, of course. So for people listening in, they just want to know a bit more of the background. So the ceremony is basically needed to generate the verification keys, which are like sort of public keys that go in our smart contracts that can verify our zkps. And so we store these industriality smart contracts that we deploy on Ethereum and on Vera chain, and in the move we deploy on movements and same on the Solana.

Process of Generating Keys

Once what we did so far for Testnet was we generated those ourselves with the union labs team. But this generation process has one critical step, while you generate a few random numbers, and those random numbers need to be deleted, because if you don't delete them, you can later basically hack the smart contracts. You can create zkps which are not valid, but will be accepted by the contracts.

Importance of Secure Deletion

So it's very important that these numbers are safely deleted. Now, obviously, like we trust ourselves at union labs, we built the protocol, but the wider crypto community cannot technically trust us, right? We're humans after all. We could have been hacked. We might have had a north korean developer. You don't know what can occur.

Decentralization for Security

So there's basically a solution to de risk this, which is don't have one computer generate this number, but do it over many computers. Obviously, if you have all of the union labs team members participate, you've already de risked it, because if one of them turns out to be like a north korean hacker, then at least like you spread it out over the team, and so it's no longer vulnerable.

Involvement of Community

But even better is if you just open it up to the community, right? Instead of ten people participate, have a thousand people participate. And the way this setup works is as long as one person in the whole chain of people participating truly deletes the secret numbers that have been generated, then the full sequence is secure.

Ensuring Security with Participation

Even if 99.9% of the participants were all north korean hackers, as long as there's one honest contributor participating, then in the end, our circuits are fully secure and the system itself is secure. So the approach we've chosen ourselves is a. The Unlabs team participated first in ceremony. We mainly did that to just test the UX.

Phases of the Ceremony

Now we're in the private phase. That's where we reward some early contributors, some partners that have been working with us so far, and ensure that they can participate. Where we actually handed out invitation keys at Token 2049 as well in Singapore. So we had a whole bunch of different founders there already join us in the ceremony.

Looking Back at Historical Ceremonies

And the second phase, which is where we open this up to everyone, and that's where we expect the largest influx of participants to come from. Now, looking a little bit back, historically, you mentioned Zcashenhe. I think they went in a forest right. Together they truly did the ceremony as in like leave your mobile phones behind.

The Forest Ceremony

We're all going into a forest with a laptop and we each put in our numbers. How did they do this again? Yeah, I think like it's so. It feels like from another age because I think the trustee ceremony was just sort of like six different parties or four even. I don't recall exactly the number.

Random Number Generators

And I think each of them went very deep into finding different sort of like random number generators in weird ways and then sort of like destroyed their, you know, the systems that they created the keys with. So I think, I guess, you know, it's sort of like at the other end of the spectrum, like when you have like four people, like you did the risk much less.

Community Participation vs Trust

So you're kind of relying more on the trust in some community members. When you go from sort of like massive amount of community participation, then you are the risk in the sort of like this trusted ceremony in a totally different way. And, yeah, I mean, I think it's just kind of also looking to it from.

Perspective on Security

With my security hat on. I think like the property of just having one honest participant is very strong. I think like you guys have done an excellent job just making all the components open source and making it easy for third parties to verify as well that some of the components in actually executing the ceremony, like the NPC system itself, can be, you know, audited by the community and it's open source.

The Importance of Openness

So I think that's, you know, something quite powerful. And actually I am. I was trying to time my ceremony participation exactly as we are doing this space. But, you know, I guess that you guys have done a good job like just writing this to the community because like I've been in the queue for about 1 hour.

Expected Numbers in Participation

So right now in the queue for the ceremony, like if this is about 50% maybe I'm going to be actually participating in the trusted ceremony towards the end of this space which sort of, I guess this gets recorded for posterity. And I guess in terms of numbers, do you guys have sort of any expectation of the numbers of participants that you expect to have?

Participant Slots and Hardware Quality

Yeah. So the number of participants kind of depends on the hardware of the participants themselves. So for the people that have participated already, you might see in the UI that you get a slot and a slot is a 30 minutes window in which your computer can generate those random numbers and participate. What we've noticed is that the quality of the hardware that people use for the participation differs a lot.

Contribution Duration

So for some, they're kind of done contributing in about six to seven minutes.

Participant Slots and Ceremony Duration

Others, they barely make their slots. They're done in 29 minutes or something like that. So if on average it's 30 minutes per participant, then really you can only at most have 48 participants per day. Then the next thing is, how long do we want to let the ceremony run for? That depends a bit. Most likely the public portion will run for approximately a month. So people can do the math on how many participants will have at the least, and the most with the numbers we have so far, according to our calculations, the wait list already exceeds how many will be able to participate. And that's just kind of a fundamental limitation of, I'm afraid, the potatoes that people use to calculate on.

Future Ceremonies and Performance Upgrades

For those that might miss this, there will probably be multiple ceremonies for union, because every time when we have a significant performance upgrade for our circuits, we might need to do another ceremony. There's types of performance upgrades where we just make the prover faster, the off changing file where we get that server to be more optimized and generate proofs faster. There's also an optimization where basically how our circuit is compiled becomes better, and in that case, the verification key changes and we need to do another ceremony. So I kind of expect that probably once every six months to one year, union will do a potential ceremony to upgrade. Certain contracts will just have to depend on what the performance gain will be. So if we can get a 50% fast approving time, that's very significant for the UX. And so then it's worth it for us to run a ceremony again with rewards for the community that participates.

Community Involvement and Security

So for this one, we basically have the patron NFT to show that you really helped us create the union as well as for early supports on our testnet. And then for the second one, we need to figure out how we reward you. Yeah. And I guess just from my sort of like, sight as a community member. Yeah. I would just encourage everyone to participate because I think it's fun, you know, like it's one of these things where technologies, I mean, I wouldn't say it's like magic, but it's just very cool to participate in multi party computation protocol, like a CK trusted ceremony. So it's nice that you get an NFT, but I would just say like, just do it because it's pretty cool to be coordinating in this way with random folks all over the Internet.

Importance of Participation and Contribution

Internet just making a protocol sound. Yeah. And I particularly like this because you're truly helping us make union a lot more secure. Right. This isn't just some, I don't know, publicity stunts that we're doing. This isn't referral codes to get additional points. This is actually a critical step to make this system secure. So I think everyone that manages to participate should actually feel really proud of doing so. You've helped make something great and basically facilitate crypto becoming once again a little bit more decentralized and a little bit more secure. I think that's always something to strive for at the end of the day.

Theoretical vs. Actual Security in Protocols

Yeah, 100%. And, you know, like, I'm not sure exactly for how long we have the space schedule, but there is something that we have time. I would love to dig a bit deeper with you. And that's something that we've chatted about, and I've seen you also tweeting, which is something that I think a lot about, which is sort of like the difference between theoretical security and actual security for bridges. And what I'm getting to is that, as we know, there is a lot of these bridge hacks in the past have been actually not like design flaws, but actually configuration implementation flaws. And you see, like, in many bridges in the ecosystem or many interoperability protocols that talk about a lot about their security properties and their designs and how secure they can be. But actually, when you look at the different configurations, they ended up being sort of like in the minimal, secure and decentralized way that you can actually configure these systems.

Security Configuration in Protocols

Right. Namely like one out of one or one out of two. Like, or two out of two multi six. So I love to get your thoughts on that. And, you know, like, how, and also how union compares to those systems in the sense of what's like the minimal security configuration for union, the default one, which is actually not just theoretical, but actually the implementation of union itself. Right? Yeah, yeah, exactly. So just for people wondering what actually mean by, like, what's theoretical security and then a configuration mistake. So a lot of the times what a project will describe in their white paper with, like, fancy algorithms, formulas, etcetera, that portion is actually secure.

Implementation Errors and Examples

But when they then write smart contracts, put in the numbers, configure these contracts and deploy them, they make a mistake, and they don't actually implement what's in the white paper. And usually this occurs not when they first deploy it, but might occur actually like a year down the line when they performed a few upgrades, because they might have been, like, secure originally, and then there were new devs coming in, they added some new features, and while adding a new feature, they refer to the security measure. I think Li Fi is a good example of this. Right, where they is it twice or three times they've been hacked because of the add extensions and new features to the protocol instead of the original code base with bridges. There definitely have been a few cases where the fundamental protocol is just insecure, which is an example.

Bridging Protocols and Design Flaws

Yeah. All the multi seq, you know, is plots like Axie bridge, like that. That's definitely like a design exploit. Yeah, yeah. You can configure it. You know, like you can configure one of these more like message swapping protocols as well to rely on a multi seq. So, so if you are able to get hands to the multi seq, like you are actually exploiting the design as well, right? Yeah, yeah, exactly. So anything that's like multi sick, I would say, like if the multi SIG participants get hacked themselves, that's a design flaw. Like, you knew the system was fundamentally vulnerable to this. That's not an implementation detail that you missed. Like, that's just because you chose a bad design for the bridge.

Mistakes in Smart Contracts and Security Flaws

You had Nomad, and Nomad just made a mistake in their smart contract codes. Like, I don't think they were audited at the time too. So that was a bit only the company itself. But I think their protocol was fundamentally quite sound. Still a bit risky with like, always need to have a disputer live for their Oracle updates, but fundamentally sound. And they got hacked because they just had errors in the way they coded their smart contracts. Now how I see it right now in the bridging space is we kind of have like three categories.

Types of Bridging Protocols

We have intent based bridges which use an oracle to repay the market makers solvers. They are vulnerable to have their Oracle hacked. And the funds that are like at the moment locked to go back to repaying solvers, those could be stolen. We haven't really seen that occur and that's usually because these oracles have like high latency to them. Like they're very slow to create a proof or update on chain and there's loads of layers to stop this proof from arriving, which isn't great for solve, or UX, which takes a while for solvers to get their money, but keeps it quite secure.

Security Levels in Bridge Protocols

Then we have what you see layer zero v two do in XOR now as well, where there's like all of these different configurable security levels, different like verification contracts that have a certain stake associated with them and loads of configuration parameters and high customizability, which hyperlink has as well. And then you have protocols like union where there's basically one big security level and everything that goes through union is at that security level. There's one ZKP to verify and there's not that much configuration for individual chain, at least it's as little as possible. I like our approach more because like you said, a lot of bridge hacks are actually due to configuration error.

Error-Prone Configurations in Developer Protocols

So I don't really like the model where you have to think as a developer, like which DvN do I pick? How much security do I decide? I put it at like 40%. This or this is a subset of operators I trust because they just gives you so many things that you need to get correct while configuring your bridge service that there's a lot of room for errors for this to go wrong. Well, basically the philosophy of just put HTTPs everywhere, right? Put everything at the highest security level you can.

Layering Security in Protocol Design

Don't make builders that use the servers think about security. I think that's better to reason about overall, and that's better for protocols building on top to reason about, right? Because you don't want to think, oh yeah, I'm like, I'm a cross chain protocol communicating with another cross chain protocol. They're using DVN three, which is backed by a dual stake of Chihuahua coin, and three operators where all three are anal. Can I actually trust the bridge messages coming from that? Probably not. And that's, I think, how we see a lot of avenues for tech.

Technical Debt in Protocol Development

And the other thing is, the more you can configure, the more middleware you can add yourself, the more you have to implement as a developer, the more technical debt we create. I think Hyperlane is a nice example of where I basically it's an open source set of libraries that you can use and you can even like implement it yourself and deploy it. But that means that there's no wider network effects, there's no like wider maintenance ship. So there could be routes that have been created like a year ago that are still kind of operating, that are vulnerable because the people originally deployed them, like never updated them.

Centralizing Technical Debt for Better Security

So limiting how much technical debt is out there and kind of centralizing that under one umbrella, I think it's much better for security overall. Yeah, I mean, I think that, you know, this sort of corresponds to like a fundamental truth, but not about sort of like cryptography or distributed systems, but sort of like human psychology, which is like, I think like we are, we tend to be lazy, you know, like we kind of default to the least resistance path and you know, like if you inspect a bit like the of these sort of like modular configuration systems, like if you look at it under the hood, like the huge majority of the value secure is actually like on the simplest configurations which makes them kind of like very simple, like multi six or even EOA.

Promoting Standardization in Protocol Security

So like one address actually being the central trusted, you know, weakest link of the protocol. So I think like just making it sort of like mandatory as I think like the HTTPs everywhere, like it's a great analogy. I haven't thought about it. I think it's a great way to put it. So yeah, like I think this approach is quite smart and just make it like a bit more of a standard. Hey, this is how you make interoperability better. And in terms of then in union, like if you make these default.

Security as a Default in Union

You. Know, secure enough and you sort of like limit the design space for upgrades or developers to actually mess up on the like bridge integration and configuration. Like what's in your mind, how do you think about like the rest of like how you think about the security union of union itself, right? Like once the trusted ceremony is done and the CK program is up and running and everything is going fine, like how do you think about the threat model? As I understand it, as a user, you need to of course trust the univilator set, which is going to be a normal Cosmos POS system.

Enhancing Protocol Security and Threat Modeling

But how do you reason about making a union even more secure and also at the implementation level? Yeah, yeah. So we'll actually have some offer you guys publishing our long term roadmap soon as well.

Security Assumptions and Guarantees

With all of the big ticket items. The thing I'm looking forward most is kind of total proof aggregations. There's proof singularity. So we're working on the first few pocs of this right now. That basically means that there's no assumption at all on union whatsoever for providing any security. Like it's always 100% and there's no assumption on the validators at all. There is. Well this is a security assumption. It depends on how you classify it. The validators could potentially censor a chain in that system. So it kind of has the same guarantees as a decentralized sequencer network then where as long as like one of the validator is honest, like there will be no censorship. If all of the validators are dishonest, all funds are always secure, but there could be potential censorship. That I think is probably the best you can ever do with the ZK bridge.

Innovations in Proof Aggregation and State Lenses

Actually as a system where you do proof aggregation, something else we've been working on, you can find that in our research is state lenses. What's cool with state lenses is it removes BFM completely in production. Union will not be running packet forward middleware, but instead creates these virtual channels between chains. What's cool with that is you then actually have access to the state route of the two chains communicating over union with each other. And that means that you can, for example, leverage naysayer proofs. So before we actually go into this proof aggregation world, you could configure your client contract to accept a disputer address. And that disputer address could be a multisig, or could be arranges address, or could be a contract that verifies ekps. That's all fully flexible. And that is what a chain can use to basically shut down the bridge or pause it for a certain amount of time in case something goes wrong here.

Bridge Security and Rate Limiting

So that ties a bit into IBC rate limits and having some sensible ways to pass the bridge in case a hack is ongoing. There's of course, like many cases, why you might want to do this, right? It could be the union itself is still fully secure, but the chains that were connecting with each other, one of the two chains itself has been hacked. In that case, you still probably want to actually pause the bridge for that duration to make sure that no funds get sent to different chains. And now there's unbacc tokens out there. Yes, sir. One question there, like, is that like, can you like pause like a specific route? Sorry. Would be sort of like a more of a system pause during the specific time. It's, you can pause specific routes, or you can pause on like the destination sites, all routes as well in this case.

Handling Incorrect State Data

So basically what you can do is you can create a proof saying union has incorrect state data for Bara chain, right? And deliver that proof on movements. And depending on that case, you could then choose, all right, like, if union has incorrect state data for a single chain, we're just going to pause everything because that means something has gone horribly wrong, right? Like could be union that's been hacked, or could be that specific chain. For now, we don't care. Just pause everything while the devs figure out what's going on, which I think is a really sensible default to have. That's very cool. That's very cool. And that, if I understand it correctly, that would potentially be complementary to IBC rate limits in the future. If I understand the mechanism correctly, in this case, you would be sort of a post function for the system, and rate limits could be just potentially caps down the line on sort of like the value of risk that you want to put for a given route.

Application Level Security and Governance in Systems

Yeah, yeah, exactly. So basically like depending on the different chain ideas, you set different contract addresses on how you want to dispute them. So if you want to generate a CKP with RISC zero, for example, for the block header, in this case, like if you generate a different CKP with risk zero that leads to a different header than you do with union provides, then you know something is going wrong. That could be that the origin chain is undergoing a 51% attack, for example. Right, and having massive reorgs and that's why you're shutting it down. And the other level is indeed the IBC rate image, which I would say is more application level security. Right? More about like has a Dex being hacked and do you want to pause that? Yeah, no, 100%.

Importance of Security in Protocol Design

It's sort of like application level. Also at the level that it operates mostly at the token swap sort of ics 20 level. So yeah, probably like it's at a different level of the stack and could be very complementary. But that's very cool that you guys are thinking on default fallbacks, especially at the beginning of protocols. Like I think historically interoperability protocols haven't thought too much about it. And in the case of events of Nomad, for example, we saw it being exploited in real life for a long time. Could have saved the project pretty much. And as you said before, it was our sound design, but it was this implementation issue. And just having these systems in place, as you guys are doing, can sort of separate a bad day for devs to actually use sunset in the project. So I'm very glad to see that you guys are thinking thoroughly on that as well.

Security Measures and Preventive Actions

Yeah, for people listening in, like these security measures are not back doors. We, for example, configure the system to allow range security to pause a specific route. But that wouldn't mean that they could take tokens out of the route. They would just pause the transfers ongoing. And we can even configure it in such a way that they can pause it for 6 hours and then it will automatically resume. Or like a larger multi Sig needs to continue the pause. And they will prevent, for example, the Nomad hack, because the nomad hack occurred, I think, while the whole team was partying. So people were emptying the bridge protocol and no one could actually contact them at the time because they were all at a conference. So in this case, what you want is for security company to just temporarily pass the bridge, wake up the devs.

Transition to Governance and Decentralization

The devs can have a look at what's going on. And then you can use a multisig with much more participants, let's say 40 different participants across the sector to prolong the pause. And even nicer of course, is if it's not a multisig but governance for specific chain. Right. So you could say that this 40 person multisec can only pass for two days and then the system goes live again unless governance of the specific chain decides to prolong it even more. And then you have a really nice mixture of very high security but also decentralization in the end where if the us government orders the security councils to pass, they couldn't pause forever. That's kind of my favorite combination.

Final Thoughts on Security and Protocol Features

Yeah, no, I agree. I agree. I didn't know the whole backstory about Nomad, but yeah, I think that especially like given that, you know, like these temporary freezes, especially for systems and bridges that are not sort of like very oracle related, like they don't really change the trust assumptions as you said, of a system and especially like if you make this specifically temporary. Right. So even the dos of like Daniel of service of like just, you know, like someone with the post ability going rogue and trying to pause the system for to just, you know, make it unavailable when sort of like these freeze functions default into a, you know, like maybe governance that can actually impose it and things like that after like some previous time.

Implementing Security Features in New Protocols

Like I think it's very smart and I think that some of the largest projects that have wornhole for example, that in the past had like this, of course, like this massive sprite, they've implemented things like that like with the wormhole governor. So I think just starting from the get go with these sort of systems as you guys are doing, like it just a massive advantage, I think because you can sort of learn where others protocols or systems have been burned in the past and just sort of like a start with a blank slate with all those checks in place. Yeah, exactly. All right. I think we're kind of arriving at the end of the time we have for this space. Is there anything like Alpha you want to give us for what you guys are doing at range?

What's New at Range

Because I saw some new features announced recently that I've been keen to test out overall with regards to the explorer and such. Yeah, so basically we pretty much relaunched the whole range platform last week and I think we've added a bunch of new features but I think the most important one is that we are pretty much opening it up for everyone to use. So like we have like sort of two different platforms like the range community platform and then the sort of like more enterprise way that we work with teams for like real time security investigations and things like that. But the community platform right now it's open to everyone and includes as well like an advanced blog Explorer.

Accessibility of the Range Platform

So you can actually visit that app or you don't even need like a sign up. So it's sort of like a, you can think of it as a battery included, you know, cross chain Explorer and you can see, you can start doing like a lot of things, you know, just investigating even your wallets or just using it as a normal explorer and even tracking in real time like all IBC transactions. So we just, you know, like we made like this very important decision that a lot of the infra and post that were building were actually not just helpful to, for like the developer teams that we work very closely with, but like at this, they could be very useful for the community at large and also, you know, like developers that we might not know personally.

Expansion and Multi-Chain Support

So yeah, like if you check out our page@range.org or even just the platform directly, you can start using range by the get go. You don't need to jump into our call with us or get at them or anything, which is kind of like what a lot of the security intelligence platforms default to. And we are making this sort of like open for everyone. And yeah, we announced as well full Solana support. So basically like we are supporting a lot of your favorite cosmos chains, like of course like Osmosis, Neutron, Cosmos Hub, DyBX, Celestia Dimension, many others, and now as well like full support with Solana.

Future Goals and Collaboration Efforts

And I guess one of our goals for the next couple of months is also to cover majority of the cross chain volumes of the space and we are going to be incorporating this into the range platform as well. A lot of these volumes are going to be coming from union, of course. So yeah, very excited for this collaboration as well. Yeah, exactly. I see already a couple of teams that we are working with to build products on top of union here in this space. I'll make sure to create some telegram channels and connect you with them because we definitely want to monitor some of the order flow they're going to be sending around for everyone listening.

Upcoming Opportunities for Users

If you're more interested in ceremony, keep following our Twitter and make sure to sign up for the waitlist if you haven't received the key yet, to get an early heads up for the public portion. Public portion as a heads up, most likely the queue will fill up within the first ten minutes. So getting that early heads up and being behind your computer and ready to join the queue ASAP, that'll be the best chance for you to get a spot because right now we have, I think almost fifteen k real accounts waitlisted with the software installed and ready to go, and probably out of those about two to three k will be able to participate.

Concluding Remarks

So you really need to be ready to run if you want to have a decent chance. Yeah. Thank you so much for coming on and thanks everyone for listening. Yeah, thanks so much for having me here and also thanks everyone for listening. Bye zkgm everyone and see you all around. Ckdm take care everybody.