SKY Protocol is a Layer 2 solution for Cardano, separating blockchain aspects (consensus, validation, data availability, bridging) to enable DApps with better throughput, low latency, privacy, security, censorship resistance, and cost-efficiency. Future versions will support all major blockchains, simplifying and reducing DApp development costs.

Data Availability and its Existing Engines
One promising venue to enable massive scaling wherein DApps can compete economically with CApps is specialized Data Availability (DA) “engines”—subsystems that specialize in one single fundamental aspect of blockchains wherein they achieve (or fail to achieve) scalability. Several projects have tried recently to provide this service. The first was Celestia, and many followed. We will call them all “first generation” Data Availability engines. It is interesting to study their successes and failures (so far):
- Celestia is historically the first project that tried to explicitly solve the Data Availability problem. What more it does this without trying to push a specific consensus layer onto its users. It therefore offers a more modular design than PolkaDot or Cosmos, that do try to have you adopt their consensus. But its threat model has a few flaws.
- Avail tries to build a Celestia-like system that will further bridge all the blockchains.
- EigenDA has a few good ideas, especially for how a token can be truly universal; however it doesn’t address some of the flaws of, and we have to see what really comes out of it.
- NearDA… ? [TODO dig deeper on competition]
Note that “rollups”, the use of Layer 1 blockchains themselves as Data Availability engines for side-chains that use them, was invented as a clever interim solution to improve scalability a little bit until either Layer 1s learn to scale properly, or a good well-trusted DA engine makes scalability happen.

The Absurdity of “Data Availability Sampling”
Many first-generation Data Availability networks feature some client-side “data availability sampling” that they claim contributes to security by detecting when network participants are dishonest. However, the technique fails to actually improve security:
1. The sampling comes too late to save any user’s assets.
2. The sampling provides no means to sanction the dishonest data availability node.
3. When unavailability is detected, the sampling cannot distinguish between bad data availability node and bad side-chain operator.
4. Dishonest data availability nodes can distinguish between usage by actual side-chain watchers and mere random checks, and only provide uselessly limited data, slowly, to those who don’t need it.
5. In its “efficient” version, this sampling does not at all check availability of the data, only a concise zero-knowledge proof of possession of the data. However, lack of possession of the data was never the problem to begin with—in a data withholding attack, the Adversary is a dishonest Side-chain Operator (SO), who does possess the data, but is precisely withholding that data and keeping the assets hostage. At that point, the proof of knowledge is just like a hostage taker sending an ear of the hostage to prove he was still alive recently—the data wasn’t released at all, and you still don’t have it, but now you know the hostage taker means business.
Client-side Data Availability Sampling is therefore worse than worthless: it comes with a lot of complexity to yield a false sense of security, and actually makes the job easier for hostage takers.

The Solution: SKY Protocol
SKY Protocol is a modular solution to Layer 2 scalability that will launch this year (2024) on the Cardano blockchain, and on other blockchains afterwards. By going back to first principles, SKY Protocol can sport a modular design that pushes the boundaries of the tradeoffs involved; it thus allows each DApp to enjoy the capabilities and capacities it needs, without sacrificing decentralization, yet without burdening the necessary resource-limited Layer 1.

Data Availability Engine
The first component we are building is a pure Data Availability (DA) Engine. This DA can help keep side-chain operators honest and build trust in a decentralized side-chain solution: a side-chain anchoring smart contract forces operators to publish all their data on the DA; then users know they and their agents too can validate the data and build models sufficient to keep issuing side-chain transactions and main-chain transactions to secure the assets. Thanks to their accurate model of the side-chain, they can ensure that they can get their assets out of the side-chain in case of operator failure, whereas no dishonest person will be able to take the assets away. Furthermore, validation of side-chain transactions is either done using interactive proofs (“optimism”) or non-interactive proofs (zero-knowledge). In the case of interactive proofs, there must be at least one honest watcher at any given time reading and validating all the transactions fast enough, and latency is added after the transactions are initially published to leave watchers time to challenge them. Following a challenge period (and potential challenges), the claims are validated (or invalidated), and if validated, users can retrieve corresponding assets from the Smart Contract based on those claims. Economically, a Data Availability engine enables many DApps to share a common economic validation network for the crucial aspect of Data Availability, just like they may share a common economic validation network for the crucial aspects of Consensus and Validation, from the Layer 1 main chain of which they are a side-chain. By sharing a network, these DApps effectively pool resources together to achieve greater security against economic attacks than possible if operating apart.

Topics and Shards
SKY Protocol achieves parallelism by dividing its network into mostly independent topics. Each topic is being served by its own topic committee that accepts data, makes it available to watchers, and publishes attestations to this effect. For the sake of attack-resistance (which subsumes fault-tolerance), each topic is further divided into shards, each served by a single committee member, such that only a fraction of the shards is enough to reconstitute the data being made available: at least 67% of the committee must sign an attestation of availability for it to be considered valid, and at least 34% of the committee must actually serve the data for the data to be available. Finally, time is divided into slots of half a second during which the committee is tasked with accepting new data for the topic, and in publishing periods of a week during which the data remains available. Each topic achieves consensus about what data was served, what fees were collected and earned by whom, which committee members misbehaved (if any), and any other relevant metadata. Consensus about what happened during a time slot will take the duration of several time slots before it converges. Each topic has relatively small limits, which guarantees that watchers can’t be flooded by attackers while listening to the topic. To scale, a DApp may require its watchers to watch as many distinct topics as necessary to fit its expected usage load. Changing the number of topics and specific list of topics for a DApp may involve consensus updates on both the main chain that the DApp is hanging to, and the Data Availability layer.

Autoscaling
As the total use of the Data Availability platform grows, more topics need to be added. If some topics are empty while others are full, we will want to somehow group together topics that are not full under a single committee, with shared limits between them. Conversely, when a topic is subject to a lot of contention between DApps (or with spam), one solution is for a topic to provide a reserved bandwidth for a single DApp. At least in a first time, the adaptation will be done outside the DA itself, by the applications using it: those with low throughput for the DA (but high for the Layer 1) may want to share a topic with no authentication (or shared authentication) with other applications. In the future, topics could be enriched with more and more general validation rules beside checking a signature, choosing between stateful or stateless interactions, configuring the remanence (duration that data remains available). Existing systems do that by requiring DA node operators to collectively possess economic expertise and vote every so often to set the right side for the pool. But the real innovation will be for topic reservation to be a double auction with the Sky Protocol as a single collective seller (for security reasons, based on median price or some such?), and block publishers as buyers. As contrasted with first-generation Data Availability networks, Sky Protocol will be a DEX for Block Space. Now, any change in the consensus with regards to topics—how many there are, how they are grouped or reserved or validated in any way, is subject to voting by humans, because any fixed and known auto-scaling algorithm can be gamed.