We are long due for an update on SkyeKiwi, and here we are, delivering our stories along with the holiday spirit and wrapping up the year. Looking back 2021, it has been quite a journey. Time passes quickly, and there still are infinite amount of work to be done in 2022 and in the future. WARNING: this is 15-min long read and a little bit technical.
My (SkyeKiwi) Story Behind the Scene
The domain “SkyeKiwi” was registered by Song long time ago, possibly back at high school, when the .kiwi domain TLD was first offered by an Australian company. For no particular reason but perhaps my name, “SkyeKiwi”, sounds cute and Song has always wanted it to be used for a cool project. Song and Zoe started to think about the SkyeKiwi project during the Christmas time of 2020, initially as an authentication layer for injecting Web3 identities when cloud hypervisors initialize cloud VMs or containers. They were introduced to a Polkadot hackathon organized by Parity Asia in March 2021. Song and Zoe built me as a demo password manager and won the third prize. Song shifted away from his responsibilities of a VC fund and started to dig into this new creation full-time. Later of the year, Zoe decided to quit her full-time job, and fully committed to the adventure to accelerate things. Now it’s the Christmas time again and we are proud to say that we have done a shit ton and glad to see how an experimental idea about me turned out to find values in ways completely unimaginable from where I was created originally. With HUGE thanks to those who had faith in SkyeKiwi and everyone who supported us along the journey, we’d like to go through a few parallel tracks that we worked on over the year.
Without Further Ado:
SkyeKiwi Protocol & IPFS
SkyeKiwi Protocol was first created for sharing a file through the IPFS network and be registered on-chain. It went through many iterations. Starting as the internal core of a password manager to share an encrypted file of passwords and credentials. In May 2021, we were introduced to the core team of the Crust Network. For those who are not familiar with Crust, Crust Network is a decentralized IPFS pinning network built within the Polkadot ecosystem. The team of the Crust Network encouraged us to extract the core secret sharing mechanism out and build it into the SkyeKiwi Protocol and the foundation that incubated the Crust Network, the Decentralized Cloud Foundation rewarded us a grant. About one month later, we made the delivery on the grant and the protocol went through its first few iterations. We completely rewrote the whole code base and established the two-step encryption schema as we are having now and enable the protocol to share a few bytes to GBs in size. We took the approach of streaming and chunking that breaks a file into many smaller pieces and processes each one separately and later encoded everything into a fixed size pre-seal metadata and encrypt the data to the sealed metadata that was later registered on chain.
A funny thing that happened on the grant evaluation: the IPFS failed. A decentralized IPFS network has a thing called “sealing time”, which is the time takes before the network is aware of the need to pin a file, to the time when the availability of the file is guaranteed on chain. Usually, it takes somewhere from 5–6 hours to a few days. Even as a fast sealing IPFS pinning network, Crust takes somewhere from a few minutes to 2 hours. It’s the price to pay for decentralization. Therefore, we posted files to Infura before the blockchain network fetches it. However, the grant evaluation team in Asia was having trouble reliably communicating with the Infura servers. We ended up deploying a few IPFS nodes ourselves and run a container that check for on-chain status and remove the file from our servers (to keep the networking cost low) when it’s sealed. This is a purely ugly solution.
After we got all the metadata and cryptography done, we started to look into it. Generally, there are economic incentives for miners in the Crust Network to compete against other nodes on receiving the users’ files, so that they can fast-seal and got rewarded by chain. Therefore, if we make the end-users generate a signature of their addresses and attach the encoded signature to their HTTP calls authentication headers and directly post the HTTP requests to the blockchain nodes. Later on, the IPFS gateway that does the on-chain account validation will directly have the blockchain take in the request to pin the file. It ended up solving the problem smoothly. Users won’t even realize that they are pinning to a decentralized IPFS pinning network.
At the same time of solving the IPFS issue, in August 2021, we updated our TypeScript repo to be a monorepo and adopt the CI/CD pipeline of PolkadotJS, which basically established what it looks like visually now for the SkyeKiwi Protocol Repo and finished the major development phase of the SkyeKiwi Protocol. In the following few months, we made lots of tweaks to reduce the memory copying/referencing and the size of the pre-seal metadata from unknown size to a fixed 146 bytes and finally to 114 bytes. We might go through some of the major tweaks in later sections of this blog.
SkyeKiwi Network
In April 2021, we had lots of options on what we’d build our technology into. Secret sharing is a far more powerful primitives in Web3 than most people thought, including ourselves. We considered identity management, wallet management, NFTs or anti-MEV DeFi. One night, walking down the street after a few drinks, we decided that’s enough of hesitation on going left or right, let’s build SkyeKiwi into a secret sharing blockchain that can do all of these. The initial thought was quite naive but straightforwards. We’d have the blockchain validators be able to re-encrypt the metadata so that we can have a programable interface for updating the file’s access. In the next few days, we started to think about how to implement the tech and apply to use cases. It turned out to be super un-intuitive for those who are not familiar with secret sharing. Therefore, we decided to say fuck it and build a very general purpose confidential smart contract execution blockchain, so that re-encrypting the metadata can be deployed as a smart contract. The SkyeKiwi Network turned out to be an extremely complicated and delicate thing to build.
In the next 2 months, we dug into the white papers and source codes of at least 15 blockchains that either does exactly what we are trying to do or related (remotely) to the goal. The technology generally divided into two groups: TEE based arch or zero-knowledge based arch. For those who don’t know a lot on TEE, it’s based on hardware security enclaves of CPUs that ensure the blockchain nodes cannot temper with some of the runtime code. In plain terms, the miners who are executing the secret contracts do not have access to the secrets of the users and the blockchain nodes always execute as expected without any economical game theory rules. We ended up picking the TEE technology before the zk techs are more mature.
It turned out thinking about confidential smart contract execution from the angle of secret sharing brings a more decentralized and scaleable architecture than our direct competitors by solving the contract key distribution problem from day one. To put it simply: it has been hard for bootstrapping the network and allowing miners to execute secret contracts. Usually, it involves decentralized generation of contract keys and strict cryptographic and economic rules of distributing the contract keys to miners. When comes to key rotations, it can be a complete engineering nightmare. However, for the SkyeKiwi Protocol, miners join the network by passing the Remote Attestation (proof of code integrity of the enclaves), the clients generate the keys and miners re-encrypt the secret on receiving the bootstrapping request and no consensus is needed for the contract keys. The SkyeKiwi Network, for most of its time, doesn’t care about the contract keys but only work on consensus on the end-hash of the contract states. When comes to key rotations, we have room to make it more flexible. We have two types of rotations: the Small Rotation updates the identity keys of the miners. The history of the keys are not important and can be discarded. The Big Rotation is the process of using the upstream API of the SkyeKiwi Protocol to rollup the latest state of secret contracts and pack up the secret the same way as they were initialized and rotate the contract keys. Furthermore, when a blockchain nodes finish a Big Rotation cycle, they has the option of removing the contract from their local machine and opt in for more lucrative secret contracts. Finally, the data belongs to the users but not to the blockchain or the blockchain nodes (well... the blockchain nodes cannot even read the secret outside of the enclave). We made the philosophical choice to give back a portion of the transaction fees to the developers who built the secret contracts while the developers are encouraged to develop their community better and form a positive circle of profit sharing. Their contracts will be more secured when more miners opt-in to process them.
In July 2021, we wrote a white paper on the architecture of SkyeKiwi Network and shared it with a selected few audiences. Up until now, lawyers are still clearing the white paper to make sure it won’t be misunderstood as a security offering. In the near future, we should be able to distribute the white paper in public. In the same month, we made the first commit to the SkyeKiwi Network repo. In the following few months, we made the secrets pallet to handle secret registry that can be also used in replacement of the smart contract we use on the SkyeKiwi Protocol. We will completely migrate over the registry from other blockchain smart contracts to our own chain when the SkyeKiwi Network is launched.
Last but not least, we’d like to talk more on what it will look like to the secret contract developers and our plans of building it. We initially thought about building a very lightweight smart contract state machine (a WASM based VM) but later discovered that there are lots of details for it. The network functions similar to a sharding blockchain network for the secret contract execution, and for every sharding network, cross-contract calls are hard. Therefore, we decided to port an engine from a good sharding blockchain. Luckily, the NEAR Protocol VM is a great fit and their runtime engineers are very supportive. The engine is actually engineered to be very portable. For the cherry on top, we would like to have the NEAR developer community to be able to make close to none changes to their contract and deploy the contract as secret contracts on the SkyeKiwi Network. While the majority of the network is built on Substrate in the Polkadot ecosystem, with help from the Octopus Network, we can get great bridging to the NEAR blockchain. So that not all the bets on interoperability will be on the Polkadot parachain. The plan is to roll out the blockchain in phases. Building the enclave is hard and slow. Therefore, we are working very hard to deliver a PoA test-net with a few node operating partners with full capacities to create and execute secret smart contracts in Q1 2022. While receiving feedbacks on the development toolchains and test out the in field execution capacities of the blockchain, the enclave will be built in parallel. By the end of Q2, 2022, we should be having a PoS test-net ready to launch, which will be turned into the main net when more engineering and economical testing are passed.
KiwiSign and Other Use Cases
We are gonna build and deploy many DApps on SkyeKiwi Network and other chains. KiwiSign is a decentralized legal contract signature platform. We started to think about KiwiSign when attending another hackathon organized by the Web3 Foundation and built out a quick demo. We won the first place of the hackathon. We are proud of the mechanism design behind KiwiSign and it is completely built with the SkyeKiwi Protocol and does not need to be executed with the secret smart contract execution environment. The idea is simple, from the first principle, signing legal contracts involves delivering a PDF file, and notarize one’s signature of agreement to the content of the PDF file. We have built the primitives to solve the first part. We hack the second part by using a field called sealing-key within the metadata of the SkyeKiwi Protocol. It’s a 32 bytes key generated from the client and only the desired recipients have access to this key. The key is initially used by the SkyeKiwi Protocol to symmetrically encrypt the chunks. If we make the sealing-key generated as a secret key on an elliptic curve, the key can be used by recipients of the file to generate proof of access to the file. Therefore, we structured the resulting smart contract of KiwiSign to be small (about 30 lines of code), that records the public key (or ethereum address) derived from the sealing-key along with the secretId generated from the on-chain secret registry; and signing a contract at the very core is: 1. do an ECRECOVER to verify that user’s signature against the public key recorded and 2. issue an NFT to the user with URI containing the hash of the secretId. And that’s it! For any contract signed. We are exposing close to none information to figure out who sign the contract but can easily verify is one claims that they has signed one. Cryptographically, outside the PDF files, contract recipients can’t even know who are their co-signers.
We run into some issues when actually building the product. Well, first of all, we are not front-end experts and compare to all other initiatives, KiwiSign seems to be less prioritized. The one major technical challenge is for wallets integrations and the cryptography support from wallets. It’s a (somewhat) less known fact but it’s impossible to derive the public key from an ethereum address. However, as long as the address has made one transaction, the public key can be derived from that transaction. Also, asymmetric encryptions used by the SkyeKiwi Protocol is based on ECDH. From blockchain wallet 101, DApps do not have access to the user’s secret key. It’s generally a bad idea to build a wallet from scratch. So, we opt into shopping a good solution from the market. Turned out, Metamask exposes an interface to do ECDH on secp256k1; a Web2 identity to Web3 wallet provider called Torus has an underlying field in the HTTP response that has the raw secp256k1 point of the public key alongside the ethereum address, and they use Metamask under the hood as the wallet engine. Lastly, we target our audience to be less blockchain native as DeFi applications, therefore, gasless transactions seem to be essential. We talked with the Biconomy team for integrating with their gasless infrastructure and their APIs seem to be clear and straightforwards. Ethereum compatible blockchains like Moonbeam and Polygon would be great host of the smart contract. Sometime soon in January, we should be finally have a team to put all these little pieces together and deliver KiwiSign.
For others applications, a Metaverse project is gaining priority. It is a nature themed digital immersion with NFTs and Metaverse scenes base off real-world landscapes, endangered wildlife etc. Fundraising for habitat restoration and the process of bringing the education of those restoration efforts to the public have been extremely difficult due to the lack of a good economic model, and relying on charity is not self-sustainable. The scientifically proven accurate models of nature as NFTs are essential building blocks for the future of Metaverse and reality games. The auction proceeds of these models go back to the habitat restoration efforts to form a positive economic flow. Web3 technologies align the interest of multiple parties to create a sustainable system of nature preservation. SkyeKiwi technologies will be used to build the some of the basic primitives: with SkyeKiwi Protocol, the encrypted NFTs where the access to the URI of the NFT can be controlled. Paid subscribers got access to the content while others cannot. Owners of the NFTs can mange the visibility of the content as public or access-controlled. The changes of URI will not affect other properties of the NFT as it will be compatibly with existing standards and tradable on any NFT marketplaces. We are also building primitives like importing objects to the Unreal Engine, DAO for votes on restoration efforts to take place, storytelling platform for educational purpose etc. Apart from these, all the Metaverse content and collections will be stored on the Crust Network for short-term or permeant storage.
Lastly, it seems like a new trends of DeFi is quietly gaining more attentions. The staking for payment model can (arguably) be the ultimate solution for micropayments. When working on the Web3 Authentication IPFS Gateway(ref to the SkyeKiwi Protocol Section), the pinning of the IPFS file is not achieved by sending a transaction but simply by attaching an authentication header to the HTTP request. Therefore, it is not a trivial question of how the end-users can elegantly pay for those files. The solution turned out to be the gateway can check for a user’s DeFi position of CRU (the native network token of the Crust Network). After some rough calculation of the DeFi profit and the cost from processing the file on storage and gas fee of the Crust Network, it turns out that the profit covers the cost perfectly while still gives the user a great return from DeFi. Furthermore, when the DeFi protocol passively keeps generating profit, the protocol will be self-sustained to infinitely renew the cost of storing the file. On even the costly end of the network cost, one can store a movie for thousands of years with a dollar of downpayment. Permeant file storage is a great application of such model but we think it can go way further than this. For instance, KiwiSign can be free to use forever, as long as the contract sender stake a few native token of the SkyeKiwi Network, that most of our early users will do either way. Furthermore, the Substrate framework is very flexible on transaction payments. We can tweak the parameters to allow users to make a certain amount of free transactions every day depends on how much token they stake, while a portion of the staking profit can be aggregated to the on-chain treasury and compensate the miners. It’s a neat convenient feature for the end users. The Acala Network (the DeFi blockchain in the Polkadot ecosystem) seems to have implemented some of these mechanism, while the Crust Network uses such mechanism to discount the miners for the cost of submitting work report verification transactions. For the SkyeKiwi Network, estimating the off-chain TEE secret smart contract execution gas can get very complicated, and such model might be a way that makes both us and developers’ life better :) If we can put together a collective of blockchain teams for making these “staking as payment” model more popular, it would be absolutely awesome.
All Other Things
Frankly, we realized that we might be too silent in 2021. It makes senes that all the architecture and engineering require a high level of focus. The default desktop image of Kali Linux (a pen-testing Linux distribution for hackers :) has its famous line: “the quieter you become, the more you are able to hear”. As founders, we always need to balance how quiet and how loud we are. We had done a great job in 2021 to be quiet and hear more. In the coming year, we will be much louder. Well, inside those quietness, we started SkyeKiwi by winning the one hackathon from Parity Asia in April, followed by an accepted grant delivery to the Web3 Foundation later the same month. Then, we were granted by the Decentralized Cloud Foundation for the work on the SkyeKiwi Protocol and building on the Crust Network for IPFS storage in May. In late May/June, we won the first place by the Web3 Foundation hackathon and entered into tons of work behind the curtain and wrote the SkyeKiwi Network white paper, updates the SkyeKiwi Protocol etc. In August, we updated our deliverables with the Web3 Foundation to better reflect our work on the SkyeKiwi Protocol and 2 months later, we were granted another grant for the work. At the same time, in October, we were accepted into the Substrate Builders Program by Parity to be helped with everything on building the Substrate based blockchain. Countless meetings and revisions to the architecture to where it is right now with all the amazing people who have helped us along the way from technical teams to investors. In November, we updated our website, and we finished our angle round of fundraising which we would share more details after we finish the seed round.
Bottom Line
Well… we are always hiring & always enjoy talking with other cool projects. Rust engineers on Substrate or TEE are always welcomed etc. Shoot us an email at hello@skye.kiwi if you’d like to join our team and the community.
Stay tuned.
Drop us a message to:
Email: hello@skye.kiwi
Telegram: t.me/skyekiwi
Twitter: skyekiwi_team
Website: https://skye.kiwi
