🥇 First place winner at EthSF 2022! (submission) 🥇
At Snapchain, we’re building a permissionless peer-to-peer network to create and manage ephemeral blockchains seamlessly. Our solution enables developers, creators, and enterprises to spin up blockchains with an indicated time-to-live (TTL) that deletes itself at expiration to best suit the particular application or use case, saving cost, processing power, and storage capacity.
Existing smart-contract blockchains cannot be deleted. This is the problem that inspired us to create Snapchain. Certain data on the Ethereum blockchain, such as transaction data, account storage, and block header, exist indefinitely. Dead contracts no longer in use are still incurring costs, processing power, and storage capacity. The data on these contracts should be deleted to free up resources and make space for new and active contracts.
On Snapchain, users create a new chain by indicating the desired TTL, network name, and currency symbol. The created chain is assigned a Chain ID and RPC URL. This chain is alive until the TTL expires or it is manually stopped. If the chain has served its use, users can manually stop the chain from creating new blocks and receive a refund for the time remaining. After a chain has been manually stopped or reaches its TTL expiration, a mandatory 7-day grace period is enacted for security and auditing purposes. Once this grace period passes, the chain is destroyed.
Both the create chain and delete chain flow follow a similar framework. Users connect with their Web3 wallet. On the web front end, they create a new chain that is sent to the Ethereum Mainnet Contract. Once a transaction confirmation is received from the ETH Mainnet Contract, an RPC call takes place to create the chain on Snapchain’s P2P node. This node creates an EVM node and broadcasts the message to the entire network. Receiving the message, the other nodes in the network create their EVM nodes and continue the broadcast.
Snapchain can be applied across industries and verticals in many applications and use cases to provide significant value. For example, Snapchain can (1) make Web3 implementation affordable in PvP games by only storing data for the length of the auditing period; (2) enable the next wave of social media and messaging apps in Web3 that are inspired by Snapchat, Bereal, and Signal; and (3) act as a Testnet for Alpha and Beta releases that minimizes hacking and other exposure-related risks.
Immediate iterations to be made post-demo release include: (1) Bridging assets to and from other EVM chains; (2) Providing on-demand explorer for ephemeral chains as an Explorer-as-a-Service; and (3) Enabling other Web3 wallet interactions besides MetaMask.
Future iterations to enhance the solution for release include: (1) Topping up chains to extend the TTL period as needed; (2) Capping chain size to set rules that best fit the data-recording scenario, such as only recording data of the 3 latest months; (3) Making chains customizable to better cater for different use cases, such as the proposer being able to specify that only themself can deploy contracts on the chain; and (4) Enabling a kill switch on bridge to freeze the chain and release funds locked in the bridge back to the original owners in case of a security breach or emergency.
Join Snapchain in welcoming ephemerality into Web3!
Snapchain is composed of solidity contracts, react frontend, a backend that leverages Golang and node.js, and a suite of other DevOps-related tools. The react front end utilizes styled components, AntD design system, and ethers.js to connect with the blockchain. We perform several checks on the front end to ensure proper wallet and network accordance. The backend utilizes node.js to execute gRPC commands, libp2p instructions, and various Goeth-related command line prompts. First, after a chain is created from our front end, we do input validation such as making sure the nonce and TTL are proper. Second, we select a random Chain ID and generate a genesis file to launch the genesis block of the chain. While this is occurring, we also prepare our Docker-compose files by preparing them with the proper node key files, Keystore dir, ports, etc. When these files are properly generated, we start the get instance and broadcast a message to the rest of our network. We utilize IPFS's libbp2p to automatically transact much of the above, and we allow peers to be discovered by each other. The solidity contract is comprised of smart contracts that create our snapchain, our SNAP ERC20 token, and permits. Our snapchain keeps track of each user's deposited amount of $SNAP. $SNAP is needed to create a chain, and the amount deposited determines the time to live for each chain. If a chain runs out of $SNAP, it will auto-destruct. Of course, a user also has the power to manage their chain and destroy it earlier, if they so choose. Our chain also has a function that calibrates the cost of $SNAP and helps indicate to users the remaining lifetime based on the amount of $SNAP deposited.