Skynet Substrate SDK

Search…
Introduction
The Skynet Substrate SDK lets developers in the Polkadot ecosystem build Skynet interaction directly into their blockchain projects.
Substrate allows developers to create specialized, application-specific blockchains with extreme freedom and flexibility, which can seamlessly connect to Polkadot or Kusama or run independently as solo chains.
Substrate is a highly modular framework and allows for nodes to run “off-chain workers” outside of the rigid time constraints of block production. Our Skynet Substrate SDK allows for the easy creation of Off-chain Worker Pallets that nodes can call directly for off-chain storage.
To learn more about Substrate, check out the Substrate Technology Overview. You can build a new blockchain in a few hours.
New to Skynet? Check out Skynet Basics to learn how it works. We’ll also link to additional documentation where additional context is needed.
Overview
skynet-substrate contains the code necessary to do the following Skynet behavior in an off-chain worker:
Download & Upload Skyfiles
Read & Write from the Registry
Update Resolver Skylinks
Repin existing Skylinks
Set a URL for specific portal interaction
In addition to the Skynet Substrate SDK technical documentation, we also have a repo for a simple runtime with a Skynet Offchain Worker Example Pallet and a corresponding example Vue frontend.
Why Skynet + Substrate?
Using Skynet, your Substrate runtime can do things like auto-pin NFT data, publish pieces of application state for access without a centralized API, or communicate cross-chain using a robust, decentralized, off-chain data layer.
Using Substrate, you can also extend the functionality of Skynet! You could build applications that allow groups to control a resolver skylink or even allow users to announce their MySky UserID and let the runtime build and publish social graphs for your application.
Overview of Example Node and Frontend
The best way to get started as a substrate developer is to first understand Skynet Basics, then continue to the Example Pallet, which shows the simplest ways of interacting with Skynet.
In this section, I’ll walk through the behavior of the pallet code. It is an off-chain worker that is triggered after every block. Each header will show a Skynet interaction and break down the behavior of the off-chain worker.
This example node interacts with a “historical height” from Skynet to calculate an “average block height” — a weighted average of the current block height with a the previously calculated average written to Skynet.
This is a useless piece of data, but shows that we can grab data off-chain, modify it with information from our current block, and then persist the result off-chain for use by the runtime or by a browser client reading from Skynet, fully unaware of the blockchain.
Create a resolver skylink (L104-106) from a public key and data key (L60,62)
Files on Skynet are immutable and referenced by a skylink. Resolver Skylinks are a special data type that can be updated and that point to other skylinks. We do this to know where data has previously been written by the runtime.
Use this skylink to download existing data from Skynet (L174)
Next, we call a helper function that downloads the data that the resolver skylink is pointing to. The data in this example is the “historical block height” of our chain. Starting in L177, we handle what to do if we get an error, but if the resolver skylink exists, we’ll decode the data as a number (L190) and return the value. If not, we’ll return None .
Then, in L116-126, we use the returned value for calculating a new “average height” — if the skylink doesn’t exist, we’ll seed the value with the current block height, otherwise, we’ll take a weighted average of the current block height and the value we got from Skynet.
Finally, we encode the result as bytes before uploading the value to Skynet.
Upload a file of the calculated value to Skynet (L131-136)
Starting in L132, we’re creating a skyfile by uploading a collection of bytes to Skynet (L132). The data in this file is our &average_height_bytes (L133) and we’ll name the file after our DATA_KEY (L134). In Line 135, we can supply a timeout time, but could supply a number of UploadOptions. The result, if successful, should be a skylink in byte form.
Update the resolver skylink to point at the skylink of the uploaded file (L143)
To update a resolver skylink, we need to provide a private key to sign the update, the data key that lets us “tweak” the lookup (and have many resolver skylinks for a single public key), and the skylink we want the resolver skylink to point to. Now, the next time the off-chain worker goes to read the resolver skylink, the Skynet portal will return the value of the skyfile uploaded in the previous section.
The Front-end
The front-end example differs from most substrate projects, in that it doesn’t use polkadot-js (or even skynet-js!). This shows that the client, if aware of a skylink where data is published, only needs to interact with a simple HTTP request to pull data published by our node.
Much more complex interactions are possible with Skynet, including using websockets to subscribe to information updates, but this example’s code simply fetches the skylink in the input box (L59) and then decodes the value from the byte format written by the node.
The example runtime and frontend both communicate with our public portal Siasky.net. They do not need to use the same portal, and for greater reliability and decentralization, off-chain workers will likely use account-only portals like SkynetPro.net along with Private API Keys.
Beyond the Example
This example tries to illustrate the major interactions with Skynet in a trivial example. We’re incredibly interested to see what functionality developers can build to extend Skynet’s functionality.
Some possible applications could be:
1.Handling multi-signature updates of resolver skylinks
2.Cooperative NFT data pinning by nodes or uploads of procedurally generated NFTs for off-chain storage
3.Pay-to-View Skylinks by encrypting skyfiles client-side, then selecting trusted nodes to share proxy re-encryption keys with that can be converted to another key for specific users to de-crypt files from Skynet.
4.Allowing users to publish an ed25519 pubkey along with their Nicks Pallet nickname for off-chain application data controlled by the user (see MySky), but anchored to on-chain accounts
Feedback & Support
If you’re building with Substrate and have any questions or feedback, please reach out! We’d love to hear about what you’re building.
Building the skynet-substrate was supported by the Web3 Foundation Grants Program, which focuses on funding software development and research efforts related to Polkadot, Kusama, Substrate and ink!.
Project supported by web3 foundation grants program
Integrations - Previous
Registry Subscription
Next - Developer Guides
Server-Hosted Skynet Usage
Last modified 4mo ago
Copy link
Outline
Introduction
Overview
Why Skynet + Substrate?
Overview of Example Node and Frontend
Beyond the Example
Feedback & Support