Stoica and Shenker proposed the concept of sky computing and its potential to transform the cloud computing paradigm [1]. At its core, they revisit McCarthy’s vision of computing as a utility, analogous to telephone systems. In utilities, users typically do not concern themselves with the specific provider of connectivity. For instance, in telephone systems, multiple companies compete to offer the best overall service. Although they all provide the same core service — a phone number and the ability to call anyone — they differentiate through competitive pricing, add-ons, and quality of service. This competition drives higher-quality services for customers at lower costs. However, when it comes to computing, this is not the case. Major cloud computing companies dominate the execution of most web workloads with proprietary services and APIs that lock in customers, making it practically impossible to switch providers.

Stoica and Shenker argue that creating a layer of interconnectivity standards and agreements between cloud providers could foster competition and provide developers with a cloud-agnostic standard for building and deploying applications. They also suggest that smaller clouds have the greatest incentive to initially adopt such standards, as they seek to expand their service offerings beyond their native capabilities. Unfortunately, several years after the inception of this idea, progress toward the vision of sky computing has been minimal. The high cost of compute resources, especially for AI/ML workloads, only underscores the urgent need for a solution, as these costs increasingly exclude smaller players from the market.

In this manuscript, we argue that blockchain technology can serve as the key enabler for realizing the vision of sky computing by:

• Providing a permissionless and open compute plane to power interconnectivity standards.
• Introducing financial instruments (e.g., payments, auctions, loans) to facilitate and streamline inter-cloud agreements.
• Leveraging an ecosystem of pre-existing ``clouds,’’ where blockchains offer abundant compute resources for applications, creating a competitive environment of smaller vendors eager to adopt interconnectivity frameworks.

Read more: https://sergeynog.substack.com/p/realizing-the-vision-of-sky-computing

the end.

The early internet concept of an overlay network has an important role to play in the formation of blockchain infrastructure.

The framework of a technology “stack” has been useful in understanding the function of various blockchain infrastructure components, and the role they are designed to play within the Web3 ecosystem.

For example:

• In 2016, the “fat protocols” thesis drew a line between the protocol layer and the application layer in blockchain software development, and advanced theories about where value would accrue fastest.
• Among protocols, “Layer 1 protocols” are the base layer of consensus, on which applications are built. Examples include Bitcoin and Ethereum.
• “Layer 2 protocols” usually offer faster and cheaper consensus, with lighter guarantees, relying periodically on reference to Layer 1. Examples include Lightning Network and Polygon.

Missing in the discussion of blockchain infrastructure to date is a well-known concept that played an important role in the evolution of the Web2 technology stack. That is, the overlay network. It’s our belief that overlay networks will become an important concept in the development of the Web3 stack, providing interoperability that securely connects ecosystems, assets and users.

Continue reading: https://venturebeat.com/2022/04/07/how-overlay-networks-could-change-web3/

The answer is in the unknown protocol that mostly “operates in the shadows” — the Border Gateway Protocol (BGP). It’s not as glamorous or well known as protocol suites such as TCP/IP, but it powers routing across the entire Internet. At its core, BGP helps autonomous networks operated by Internet Service Providers and organizations route and deliver traffic from one network to another.

To demonstrate what the Internet would be like without BGP, I wrote the following example scenario in a recent article for Nasdaq:

Imagine you could send an email to someone within your organization, but to send it to a friend in a different company, you would need to (a) send it to a “proxy” address, (b) use the proxy front-end to specify the destination network where your friend is at, (c) communicate it to your friend, who (d) subsequently will need to interact with the proxy to receive your email. The Internet wouldn’t be the global technology that it is today. However, to send an email, one just has to know the receiver’s email address, while on the back-end protocols and infrastructure is responsible for execution of all the steps described above and interoperability of requests across distinct networks.

Just as air traffic controllers direct planes along certain routes, BGP directs Internet traffic. The fundamental interoperability that it enables allows users from different geographic regions to connect and access any application in the world. Yesterday, when a Facebook engineer pushed an incorrect update to their internal BGP configuration, it disconnected the “Facebook network” from the rest of the world, and hence users were not able to reach any of their desired applications.

Just as Facebook needs BGP to communicate with the rest of the world, blockchains need interoperability protocols to communicate with one another. Each blockchain is like an autonomous network on the Internet — it has its own consensus, governance rules, and a software stack. But to interact with other chains, it needs universal interoperability protocols and networks to facilitate it.

The Axelar Cross-Chain Gateway Protocol (CGP) is thus analogous to BGP on the Internet. It will help us bridge networks from different ecosystems such as Bitcoin, Ethereum, Cosmos, Avalanche, and others. The protocol will enable applications to communicate with one another across autonomous blockchains. Its end goal is to empower users from across the world to interact with each other and any application on any network.

Right now, without CGP, we’re all operating like Facebook was yesterday.

Stay safe and keep innovating!

What do Facebook, Border Gateway Protocol, and blockchain technology have in common? was originally published in Axelar on Medium, where people are continuing the conversation by highlighting and responding to this story.

What is the Axelar network?

Axelar network is a decentralized state machine responsible for facilitating cross-chain requests. The network supports a few key protocols, such as Cross-Chain Gateway Protocol (CGP). CGP is at the heart of the system and allows us to easily onboard new chains with no constraints on the consensus rules and transfer information across them. In this post, we’ll take a look at what makes CGP tick and dive inside some details behind the stack. But first, let’s try to understand what led us to this architecture.

To start, here are the key components of the Axelar Network:

• Consensus
• Threshold cryptography
• Gateway contracts
• Validators
• Cross-chain daemons (aka relayers)

Why does the Axelar network need consensus to process cross-chain requests?

The rules for confirming cross-chain requests and processing them are encoded in a distributed protocol executed collectively by all validators. You can think of the Axelar network as a decentralized state transition machine, and requests submitted on the network trigger transitions from one state to another. Thus, the consensus allows us:

1. To reach an agreement on the state of the system and execute CGP,
2. Agree on the state of other chains to confirm cross-chain requests,
3. Execute distributed logic to initialize multi-party key-generation and signing protocol,
4. Handle membership changes, key-rotation, and incentives.

Finally, the consensus is a prerequisite for a number of multi-party threshold cryptography protocols which we describe below.

Why does the Axelar network need threshold cryptography?

Axelar gateways are collectively managed by the Axelar validators via threshold cryptography. That is, the majority of validators need to agree and collectively approve any transaction to be executed through the gateways. This is similar to how the majority of validators need to agree on state transitions on standard blockchains to authorize basic asset transfers from one user to another. The agreement results in a signed compact transaction. Having a single signature (collectively produced by the majority of validators) authorizing the transactions allows us to keep the transactions small, maintain low fees, and eliminate any requirements from the chains Axelar network interconnects (e.g., support for multi-signature, transaction limits, light clients, etc.). Many threshold protocols (e.g., ECDSA used by Bitcoin today) assume a reliable broadcast channel and peer-to-peer private channels between parties. This is where consensus also comes in pretty handy :).

Will every validator have to run nodes of all other chains?

Axelar network validators run nodes or light-clients of other chains. No custom logic needs to be coded for this — validators just download the software clients provided by the blockchain developers, expose RPC endpoints and point the Axelar nodes to those endpoints. Validators will be allowed to choose which chains they’ll validate requests for, and the incentives will be structured accordingly. It’s important to note that the threshold keys will be distributed across all validators for higher safety (we also have secondary keys that will be distributed across fewer validators, with much more limited power).

What types of commands does the network support?

• Generate a new chain key pair. A distributed threshold protocol is executed amongst all validators to generate the master key-pair for a chain that will interconnect with the Axelar protocol.
• Deploy a new gateway contract to a new chain. After this event, assuming a sufficient number of validators can verify transactions on that chain, it becomes interconnected through the Axelar infrastructure to all other chains. [For the Bitcoin network, custom scripts and UTXO management system is used instead. More on this later.]
• Generate a link address to transact from a source chain X to destination chain Y. This command returns a new address to which transactions can be made and subsequently the network will mint and represent them on the destination chain Y.
• Verify deposits on a source chain X. This triggers a 2nd layer consensus protocol on top of the Axelar network to finalize a deposit on a source chain. Essentially, all validators query their RPC endpoints to check if the transaction is “final” according to some rules (for PoW chains, it needs to be sufficiently deep in the chain, for PoS chains with instant finality — well, you get instant finality).

How does the state grow on the Axelar network?

The Axelar network only keeps track of information associated with the gateway contracts and cross-chain transactions. Hence, the data only grows with the amount of cross-chain transfers, and not with the size of the blockchains Axelar network connects. Furthermore, multiple cross-chain transactions are processed in batches.

What does it take to support a new chain on Axelar?

Axelar gateway contracts need to be ported to the smart contracts language of that platform. The contracts are “universal”, as they do not depend on the consensus or state of any other chains. For instance, mostly the same contracts are reused across all EVM chains. Next, a certain minimal threshold of the Axelar network validators need to run nodes to be able to verify requests in/out of the gateway contracts. The threshold is a tunable parameter in the system and will be set based on the experimentations in the testnet.

How is the information delivered across different blockchains?

When a transaction on chain A arrives at the gateway contract, it needs to be relayed to the Axelar network. Relayers or cross-chain daemons/processes are responsible for monitoring these gateway contracts, and upon seeing an inbound request, forwarding it to the Axelar network. Subsequently, the validators will query their RPC endpoints for chain A, vote on the transaction, trigger an internal state transition to process the transaction. For instance, if the transaction deposits some funds to the gateway contract, then validators record it and put it in a backlog from where it can be signed by all Axelar validators. Finally, anyone can relay the signed transaction to the destination chain.

It’s important to note that relayers are not trusted for the safety of the protocol. The decentralized protocol executed by the Axelar validator verifies (where applicable) each request submitted by the relayers. Furthermore, it’s sufficient to have 1 functional relayer to maintain liveness of the protocol.

In addition, many state transitions can be triggered by anyone on the network. For instance, when multiple cross-chain transactions are pending in the backlog to a destination chain, a single signing request on the network will process them all.

What does it take to monitor the health of the Axelar network nodes and validators?

Information about the health of the network may be observed by:

a) Monitoring the logs emitted by the Axelar nodes,

b) Querying the state of the ledger,

c) Observing events emitted by the Axelar nodes and on the gateway contracts,

d) Subscribing to the metrics exposed via Prometheus.

What are some of the interesting events that may be observed?

• Multi-party key-generation invocations, keys produced, failed attempts.
• Multi-party signing invocations.
• Keys and gateways accounts deployed to each chain.
• Active validators, their stake, delegations, whether they they miss producing blocks, or voting on events from the external chain or participate in keygen/sign ceremonies.
• Validators’ status in the network: for instance, if the validator wants to leave the network, they first have the “deregister” and wait until their shares are rotated out of the system. After their shares are rotated out of the system, they can unbond.

How can I get involved in the project?

We’re growing the ecosystem of node operators, wallet and monitoring infrastructure providers, developers, and hiring across various technical and ecosystem roles (https://axelar.network/careers)

Also, get in touch on the developer Discord and follow our social channels:

Twitter | Telegram | Medium | LinkedIn | YouTube | Forum

A Technical Introduction to the Axelar Network was originally published in Axelar on Medium, where people are continuing the conversation by highlighting and responding to this story.

Axelar network is a scalable cross-chain communication platform. Blockchain platform builders can use it to seamlessly plug-in their blockchains to all other blockchain ecosystems. Application developers can choose the best blockchain to host their applications and use Axelar’s cross-chain communication protocols to lock, unlock, and transfer assets, as well as communicate with applications on any other chain. By connecting dapps with multiple blockchain ecosystems, the Axelar platform empowers users to interact with all applications across the ecosystem directly from their wallets.

Axelar Stack

On a high level, the Axelar network is a permissionless system which anyone can join to participate in various roles. The network is designed specifically to handle cross-chain requests with high safety, robustness, liveness, and governance. At the start, the network will power two foundational decentralized protocols:

• Cross-Chain Gateway Protocol (CGP) is responsible for cross-chain routing and delivery across autonomous blockchains that may run based on different consensus protocols and finality rules, heterogeneous tech stacks, and even blockchains without smart contracts.
• Cross-chain Transfer Protocol (CTP) is an application level protocol that serves as the gateway, allowing applications to perform simple queries via a unified API (think FTP, HTTP/HTTPS) to facilitate cross-chain operations. Dapps can send CTP queries to special gateways hosted on various blockchains, and CGP is responsible for their cross-chain delivery to the correct destination blockchains, and returning the results to the sending applications.

Let’s take a closer look into each of the core protocols:

Cross-Chain Gateway Protocol (CGP)

This protocol is analogous to the Internet’s Border Gateway Protocol. While not widely known, this protocol is foundational in allowing us to route information across autonomous computer networks. Similarly, CGP is used to connect multiple autonomous blockchain ecosystems and is responsible for routing data across them. Importantly, CGP does not require blockchains to parse state of one another, nor does it impose any restrictions on the consensus rules or smart contract languages.

Platforms can easily join the CGP by setting up a regular gateway account on the platform. However, actions on such accounts can only be executed collectively by a decentralized set of node-runners supporting CGP. These node-runners are responsible for monitoring for packets coming into the CGP gateways, reaching an agreement on what should be done with each packet, and subsequently routing and delivering them to their destination gateways.

An important feature of this protocol is that it can finalize blocks of any chain via a 2nd-layer consensus executed by the protocol node-runners. This means that it can work with probabilistic chains just as easily as it works with chains that support instant finality.

Cross-Chain Transfer Protocol (CTP)

CTP is an application-level protocol. It is analogous to http/https/ftp-type protocols on the Internet. This application-level protocol sits on top of routing protocols, such as CGP and other routing technologies. Application developers can connect their dapps on any chain to perform cross-chain requests. Users can use CTP to interact with applications on any chain using simple API calls analogous to HTTP GET/POST requests. Developers can issue calls to:

• lock, unlock, and transfer assets between any two addresses across any blockchain platform,
• execute cross-chain application triggers. For instance, any dapp on chain A can update its state if some other application on chain B satisfies some search criteria (interest rate > X%),
• perform general cross-chain requests between dapps (for example a smart contract on chain A can call to update a state of a smart contract on chain B). This protocol enables the composability of programs across blockchain ecosystems.

The protocols follow principles of network interconnectivity that we outlined in the previous posts (I, II).

The Axelar platform is an ecosystem and a developer stack for cross-chain communication. Anyone can make a proposal to (1) plug-in a new blockchain into the Axelar network (and it will automatically interoperate with all previously connected chains), and (2) to add new application-level protocols to be supported by the Axelar network and its routing and delivery protocols. Community members can decide which proposals to adopt and developers can build them and deploy to all validators.

Designing a scalable cross-chain interoperability network is challenging, technically stimulating, and incredibly rewarding. Such a network can unlock new value for the ecosystem, increase asset mobility and liquidity, connect communities, and simplify user experience while using the applications across multiple platforms. Our team is not just focused on building the technology however; we are building an open and inclusive ecosystem for platform builders, developers, users, and community members.

In our next series of blog posts we will dive deeper into some of the technical aspects behind the network. To get a head start, read through the whitepaper here and let us know what you think on our social channels.

Join our community by subscribing to our social channels:

Developer Discord | Telegram Community | Telegram Announcements | Twitter

Introducing Axelar Network was originally published in Axelar on Medium, where people are continuing the conversation by highlighting and responding to this story.

Achieving scalable cross-chain communication is a complex endeavor. Interoperable systems and networks need to understand multiple existing blockchain systems, their consensus rules, virtual machine environments, security models, governance rules, etc. Can we even hope to build elegant and simple cross-chain protocols? We have a reasonable understanding of how to evaluate distributed consensus protocols : understand the network model, liveness and safety assumptions, as well as the underlying cryptographic assumptions. So how should we evaluate a cross-chain network?

If we follow the core principles of network interoperability, coupled with excellent engineering and deployment, even cross-chain communication can be secure, scalable, and elegant.

Properties of Blockchain Interconnectivity

Let’s recap the core properties that an interoperability system must satisfy from our previous blog, and translate them into the language of blockchains.

• Plug-and-Play Connectivity. Each distinct network needs to stand on its own, and no internal changes should be required for any such network to be connected to other ecosystems. In the context of blockchains, it means that platform developers should not be forced to perform any heavy engineering tasks to plug-in to other ecosystems. Of course, given Turing-complete smart contracts on some chains it’s tempting to code complicated logic to understand the state of other platforms, but this ultimately puts developers in a grid-lock where no one can upgrade without coordination with other stakeholders they’re connected to. For instance, suppose blockchain A and blockchain B would like to interoperate. Suppose blockchain A must observe every action on blockchain B and vice versa. Setting up transaction parsing rules and logic around it is a heavy undertaking upfront, but it gets even worse if, say, blockchain B wants to upgrade. For instance, if blockchain B wants to add new transaction types to its consensus, then its developers need to coordinate with blockchain A developers on such upgrades and then upgrade the transition logic accordingly. And this problem scales if blockchain B maintains N such connections to different networks. Imagine having to run a software upgrade on each one of your peripheral devices (keyboard, mouse, ipad), after each upgrade of your main laptop or workstation. Instead, the integration connectors should be as light as possible, and work as a “plug-and-play” model.

• Best-effort intermediate communication. Communication is done on a best effort basis. If a packet does not reach the final destination, it will be retransmitted shortly from the source. For blockchain systems, the source is often a user or an application smart contract, and a destination might include a destination chain and a contract address that the user/application wants to invoke. For blockchains, satisfying this property is tricky since we always want to achieve atomicity of asset and state transfers and avoid double-spending. So if a cross-chain packet is dropped, no user/application should lose their funds, and they should be able to re-send from their origins.
• Gateway-based connectivity to all blockchains. Individual blockchains should connect to other blockchains via black boxes (gateways and routers). For blockchains, this means that each chain needs to host “gateway accounts” (smart contracts). All information from applications on one chain should be routed to these accounts. Underlying routing and delivery protocols should parse the information from these accounts and deliver it to the corresponding destination blockchains. These gateways should be easy to instantiate, as discussed above, and they should not depend on the state of N networks.

Achieving the above 3 properties is ideal, but it’s relatively straightforward to satisfy them with a centralized system: put a central database between a few networks and an API/interface that users can query.

Our ultimate goal however should be to power all decentralized applications with decentralized cross-chain communication protocols. Otherwise, any centralized entity that is in the middle will eventually be able to censor and control who can use the systems and how they’re used. So what security properties should a decentralized cross-chain system try to maximize?

To simplify the discussion, let’s fix some notation. Assume a sequence of blockchains (X_1, …, X_n) want to interoperate, and assume that an interoperability network Y powering a decentralized protocol is responsible for interoperability between X_i’s. Let F be the corruption threshold that Y can tolerate (for instance, standard Byzantine protocols have 1/3 corruption threshold — in other words, if 1/3 of node operators collude, they can break the network).

• Decentralization. As we discussed, the network needs to include as many validators as possible for maximum security. There needs to be both economic and utility incentives to participate in the protocol. The community and node operators must govern the protocol. Malicious behavior needs to be identifiable and addressed at the protocol level.
• Maximum Safety. In many blockchain systems only a few miners or validators can collude to break the safety of the protocols. Since interoperability networks secure and transmit large amounts of funds, safety should be maximized on these networks such that almost all node operators would need to collude to break it. A protocol must support high safety thresholds (e.g., F > 0.9) to increase the cost of attacks. High safety thresholds combined with maximum decentralization creates a network that’s hard to compromise.
• Cross-Chain Liveness. Liveness of interoperability networks must ensure that requests from a source X_i to a destination X_j are executed atomically. So, for any two chains X_i and X_j and an interoperability network Y in the middle, assuming X_i, X_j, and Y make progress following their consensus rules, then there is a time in the future such that any request from X_i ->X_j is properly finalized within a set timeframe.
• Fall-Back Mechanisms. When threshold F is maximized, then an immediate question that arises is what happens when > (1-F) of interoperability node operators go offline. Traditional blockchains stall in these cases, however for interoperability networks we have an opportunity to do better. Interoperability fall-back property states that if Y stalls, then there is a different protocol P that can be invoked by a different (and potentially much larger) set of operators to:

a) recover any assets that might have been locked by Y, or/and,

b) fix the state of blockchains X_i.

It is important that a much larger and a potentially “stronger’’ (economically or technically) set of operators can invoke P. Otherwise, there is the potential for a direct attack on the network where an adversary might attempt to stall the network Y itself, compromise operators of P, and steal the funds.

• Shared Governance. Another attack vector that we must consider when we allow chains to interoperate is what happens when some chain X_i breaks its rules. For instance, assume that a “large” blockchain X_1 such as Ethereum talks to a small blockchain X_2. What should happen if X_2 breaks its security assumptions and, say, forks? A combination of on-chain rules, community and social governance rules must be applied to decide what happens when the trust assumptions of X_2 are violated. Should its state be frozen on X_1? Should it be disconnected from interoperability with X_1? If X_2 is connected to other blockchains X_3, … X_n, then consistency between X_2’s state across different platforms should be encouraged.

It’s easy to see how complicated the problem quickly becomes. But if you meet the core interoperability design principles and the additional properties outlined above, then:

a) There is a constant amount of work to build an interoperability protocol, followed by a constant amount of work to plug-in every new blockchain B_i. In other words, the work to scale interoperability is linear.

b) The benefits of the right architecture are quadratic: any application on any chain X_i can communicate with X_j via Y using a unified API/gateway approach.

c) The work needs to concentrate on maximizing decentralization, safety, liveness, and governance of one unified network.

By combining simple design principles with scalable architecture, we can not only meet basic functionality requirements, but can also build elegant protocols and networks that will continue to serve applications and users for decades.

The Foundation of Cross-Chain Communication was originally published in Axelar on Medium, where people are continuing the conversation by highlighting and responding to this story.

Everyday, we browse websites and interact with different content from dozens of servers, networks, and geographic locations. Each web page includes links to other websites, iframes, images, video, pop-up windows connecting it to other web pages. What makes these interactions possible? The answer is in the protocols and networks built throughout decades and APIs that sit on top of this infrastructure that make it possible for developers to send content across the globe. Protocols such as TCP, IP, BGP, and HTTP define communication standards, Internet Service Providers run the underlying networks, and interconnectivity networks, by companies like Akamai, deliver packets efficiently from one network to another. APIs such as those powered by Twilio make it easy to build on top of the stack.

Why can’t a blockchain developer offer their users the same experience? Namely, the ability to interact with other applications and assets across the entire ecosystem. Today’s blockchain ecosystem is extremely fragmented: hundreds of blockchains, dozens of bridging technologies, applications, and users scattered across the ecosystem. We’re still in the early days of ecosystem development, and several core protocols and APIs are missing that prevent us from achieving global adoption.

In the following series of blogs, we aim to understand how we got here and what we can do to solve it. We will start by understanding the history of Internet protocols and what makes computer networks tick. We will then take a look at the existing blockchain ecosystem and some of the missing protocols.

Part I. Cerf and Kahn’s principles of interconnectivity.

The need to connect networks is not new. We’ve seen it played out during the development of the Internet. Engineers figured out how to make devices talk to each other on the same network, many networks were created hosting different applications and users, so the need to connect them emerged. Routing protocols (e.g., IP, BGP), naming services (DNS), and transmission and application-level protocols (e.g., UDP, TCP, HTTP) were developed to deliver traffic across networks and autonomous systems.

Vinton G. Cerf and Robert E. Kahn laid out some of the foundations of the Internet protocols and developed the basic interconnectivity principles across networks [1, 2]. These are the essentials. You need to get them right. Building a system that actually satisfies them is a whole other ballgame.

So let’s recap the core principles that any interoperability system that connects distinct networks to the Internet must satisfy [1]:

1. No changes are required to integrate. Each distinct network needs to stand on its own, and no internal changes need to be required to any such network to connect it to the Internet.
2. Best-effort intermediate communication. Communication is done on a best effort basis. If a packet does not reach the final destination, it will be retransmitted shortly from the source.
3. Gateway-based connectivity. Individual networks should connect to other networks via black boxes (gateways and routers). These black boxes retain no information about the individual packet flows passing through them, thereby keeping them simple and avoiding complicated adaptation and recovery from various failure modes.
4. Decentralized control. There should be no global control at the operations level.

If you look at the architecture of the Internet, it resembles these principles very closely. Distinct networks speak their custom protocols offering everything from cable-based to cellular connectivity. Routers and gateways connect individual networks and route information based on IP and BGP packets. Transmission and application-level protocols are then responsible for the guaranteed delivery of specific content.

Part II. Existing Blockchain Interoperability Landscape.

Existing solutions for blockchain interoperability fit into one of these buckets:

• Centralized or federated systems. Very few, or even just a single entity is controlling and managing protocol and system development and deployment.
• “Bridges” between blockchains. We see a few centralized bridges where validators are appointed to a group of representatives, failing the decentralization objective. We also see a few decentralized systems where the state transition logic of chain A is parsed by chain B (natively or in smart contracts). These inherently fail property #1 (among others). First, they require complex engineering to develop — these are incredibly heavy protocols, and we’ve seen years for them to deploy. Second, if one chain changes, then the state transition logic on all other chains that depend on it must change. Parsing state transition logic of one network in the languages of the other and vice-versa is inherently unscalable.
• Interoperability clusters between some permissionless chain and their sister side-chains (subnets). A few projects are developing their own permissionless chains and allow clients to spin up side-chains/co-chains/para-chains that interoperate through the hub. I’m a big admirer of many of these ecosystems. They can solve interoperability between their side-chains because the side-chains speak the same language, developed and maintained by the same platform providers. But these protocols aim to grow the ecosystem around the main chain. I would classify them analogously to ISPs on the Internet that offer users good “local connectivity.” These hubs must use other technologies to communicate with other hubs and blockchains that speak different languages.

As a result, the blockchain interconnectivity protocols are at about the same state as Internet protocols were in the early 80s. In other words, there is a lot of potential for improvement! We need global naming schemes, address discovery protocols, naming protocols, scalable routing algorithms. We need those “IP” or “BGP” equivalents. We need systems that support these protocols and adhere to core principles developed and tested by Cerf, Kahn, and others for decades. Of course, blockchain protocols have their own twists and properties essential for our ecosystem, such as trust, authentication, and integrity of information.

Building the right architectures and systems that scale is challenging and incredibly rewarding at the same time. But true interoperability will unlock massive potential for the ecosystem.

In the follow-up blogs, we will dive deeper into the design principles required for blockchain interconnectivity and then discuss the approach we’re taking at Axelar.

References

[1] https://www.cybertelecom.org/notes/tcpip.htm

[2] Vinton G. Cerf and Robert E. Kahn. A Protocol for Packet Network Intercommunication. https://www.cs.princeton.edu/courses/archive/fall06/cos561/papers/cerf74.pdf

Why Blockchain Interoperability is just a Buzzword was originally published in Axelar on Medium, where people are continuing the conversation by highlighting and responding to this story.

Blockchain systems are inherently stateful. For instance, they capture information about users’ public keys, their balances, or smart contracts’ data. Subsequently, validators rely on state information to verify transactions. However, over the long-term, this state becomes unmanageable and causes multiple scalability issues. Furthermore, high storage requirements add friction to decentralization since only validators that can allocate large amounts of storage can participate in consensus.

A stateless blockchain model replaces on-chain storage with cryptographic commitments. For instance, a user can commit to her smart contract data and then append to her transaction the values that she wants to update with the associated cryptographic proofs. The traditional way to commit to a set of data, taken by Ethereum and other blockchains, is using Merkle Trees. Unfortunately, Merkle Trees are known to have very long proofs. For instance, a user that commits to 1000 values in a smart contract would need to propagate 320 bytes of additional data (cryptographic proof) to change just one of these values. In distributed networks, where every transaction propagates across all nodes, this can eat up a lot of network bandwidth and add substantial costs for nodes participating in the consensus.

To solve these problems, we designed a new commitment scheme — Pointproofs [1]. Pointproofs is a new vector commitment scheme that supports non-interactive aggregation of proofs across multiple commitments. They enable a user to commit to a sequence of values V1, …, V_n, and provably reveal one or many values at specific positions at a later time. Both the commitment and the proof size is only 48-bytes. Moreover, Pointproofs enable any third party to aggregate a collection of proofs with respect to different, independently computed commitments (generated, for instance, by distinct users) into a single proof represented by an elliptic curve point of 48-bytes! Cross-commitments aggregation is a brand new property that none of the previous constructions achieved. Pointproofs also satisfy hiding properties: a commitment and proofs for some values reveal no information about the remaining values.

When applied to blockchain smart contracts, Pointproofs allow to essentially eliminate any cryptographic overhead for proofs in a block. A block proposer that receives a collection of transactions with individual proofs can aggregate all proofs into a single 48-byte curve point. In particular, Pointproofs can reduce bandwidth overheads for propagating a block of transactions by at least 60% compared to prior state-of-art vector commitments (in specific instantiations; savings vary depending on the use-case).

Pointproofs are also efficient: on a single-thread, it takes 0.08 seconds to generate a proof for 8 values with respect to one commitment, 0.25 seconds to aggregate 4000 such proofs across multiple commitments into one proof, and 23 seconds (0.7 ms per value proven) to verify the aggregate proof.

In summary, Pointproofs can be used to reduce on-chain storage and minimize network bandwidth requirements, enabling more efficient decentralized networks.

Take a look at the white-paper and Algorand’s open-source implementation.

[1] “Pointproofs: Aggregating Proofs for Multiple Vector Commitments” by Sergey Gorbunov, Leonid Reyzin, Hoeteck Wee, and Zhenfei Zhang. The paper will appear at the ACM Conference on Computer and Communications Security 2020.

Pointproofs: Algorand Team Designs a New Commitment Scheme to Improve Blockchain Scalability was originally published in Algorand on Medium, where people are continuing the conversation by highlighting and responding to this story.

We at Algorand are committed to continuous innovation. Recently, our cryptography group announced some exciting news on our efforts to standardize BLS signature scheme. The signature scheme can, for example, be used to compress many transaction signatures into a single signature. But what signature scheme should users use to sign blocks during consensus? Unfortunately, BLS signatures and variants there-of would not work, as they do not provide security against adaptive attacks on the blockchain.

I’m excited to share more news from the cryptography group. A few weeks ago at the Swiss Blockchain School in Interlaken, I presented a new signature scheme that Hoeteck Wee and I worked on that can be used to compress signatures in the consensus and simultaneously provides security against adaptive attacks. (The scheme can also be used as a forward-secure multi-signature on transactions.).

Let me first explain the general architecture of Proof-of-Stake (PoS) blockchains. Generally, PoS-based blockchains share the following structure:

1. A committee of selected users runs a consensus sub-protocol to agree on what block B to be added next.
2. Each committee member then signs that block B.
3. Each node then appends a block B to their view of the ledger if it sees sufficiently many committee member signatures on the block B.

We refer to this collection of committee signatures on block B as the block certificate. The way in which the committees are selected and the consensus sub-protocol varies quite substantially amongst the various designs.

In recent work, we designed a new signature scheme that is the common cryptographic core of all PoS-based blockchains — namely, the signature scheme used by the committee. The scheme tries to optimize for efficiency and security:

• In terms of efficiency, the main cost of PoS protocols is bandwidth and space needed to propagate committee signatures and to store the block certificate, as well as the computational resources needed for signature verification of these certificates.

• In terms of security, we require that the signatures be forward-secure (property similar to forward secrecy satisfied by key-agreement protocols). That is, each signature is associated with the current time period in addition to the signed message, and after each time interval, a user’s secret key can be updated in such a way that it can only be used to sign messages for future time periods, but not previous ones. The use of forward-secure signatures prevents adaptive attacks on a PoS-based blockchain.

Using our construction, the set of committee signatures (S_1, … , S_n) can be compressed (aggregated) into a single efficiently verifiable signature S. Moreover, after signing on a block for round r, users can rotate their keys to satisfy forward-secrecy as explained above. Put together, the scheme can be used to build scalable and secure consensus in blockchains.

You can view the white paper here, which also describes additional details such as how we can use proofs of possessions to provide protection against rogue-key attacks, key rotation algorithms, and performance estimates.

Building cryptographic schemes is a complex process that involves theoretical design, standardization, integration, and deployment. Algorand cryptography group is excited to continue exploring advanced cryptography to optimize the performance and security of blockchains.

Efficient and Secure Digital Signatures for Proof-of-Stake Blockchains was originally published in Algorand on Medium, where people are continuing the conversation by highlighting and responding to this story.