ScyNet tech update #1
Blockchain consensus — implementation & validation challenges
Hello there, dear ScyNet reader! This post marks the first from a series of regular ScyNet development updates. The objective is to present the tech behind ScyNet while also updating you on our most recent progress — what are we doing behind the scenes? What are we challenged by? What are our next steps?
As you may know, ScyNet is all about building a blockchain network that incentivizes independent computing nodes to provide GPU resources for the training of AI agents. In this post, we’ll focus on our progress about the design and implementation of such a blockchain consensus.
TLDR: We defined the consensus protocol on paper, chose to implement it using Tendermint and Cosmos SDK, and stumbled upon an interesting problem about validating timed transactions on the blockchain.
First of all, what do we need our blockchain consensus to do? In layman’s terms, the objective is to organize timed tournaments, where the participating computing nodes compete on who managed to create the highest performing agent. To evaluate performance, we require every competing node to send a specific set of transactions at specific timed deadlines. For example, in a ScyNet domain about stock market predictions, the consensus may require all nodes to submit real-time predictions from their agents for a specific period.
We decided that it would be best to implement this protocol using Tendermint consensus — a scalable framework for Byzantine Fault-Tolerant blockchains. It handles transaction propagation and block creation while exposing a flexible API for us to write our own state machine on top of it.
If that’s not enough, we’re also utilizing the Cosmos SDK — a modular framework for creating Tendermint-based applications. The exciting thing about Cosmos is that it gives us access to modules about token transactions and IBC (Inter-Blockchain Communication aka sending tokens in-between blockchains) functionality out of the box and allows us to build our application on top of them. Our most recent progress is on designing the modules we will implement through Cosmos to allow for our ScyNet consensus logic, as well as working on their implementation.
Doing so, we also focused on resolving an interesting consensus challenge. Back to the stock market predictions example, some nodes may try to cheat by submitting their predictions much later than the expected deadline, which means that the blockchain consensus must enforce time-based transaction validation. Sounds great in theory, but in practice, if every node would validate transactions against its own clock, the small variations in these clocks will create a huge disparity between the nodes and is likely to tear the network apart.
One could propose to use the time in the block header as the deterministic source of time instead. Yet there’s a catch — in Tendermint, the time in the header of a block is actually the timestamp of the previous block. And in order to validate the transactions in a block, you actually need to wait for the next one and use its timestamp instead. For now, this seems like a plausible solution, but we’re also discussing other potential strategies with Tendermint devs in the meantime.
Great! We have a stable tech stack, a strictly defined blockchain protocol, and we are working on its implementation. Now it’s time to deliver a working Proof-of-Concept blockchain node. This will be our short-term goal for the next couple of weeks. After it is stable enough, we plan to launch a public testnet.
“But wait!” you may ask, “How am I going to learn about this?.” Thanks for reminding me! We’ll keep writing development updates, but if you want to be the first to hear about an exciting new update, seek direct contact with the core team, or have an interesting idea or suggestion about ScyNet, make sure to join us on Discord!
