Nodes
Deployed as VMs on Aleph - The backbone of Fishnet
Last updated
Deployed as VMs on Aleph - The backbone of Fishnet
Last updated
The core logic of Fishnet is written on tried-and-tested web2 technology: Python 3 & . It is simple to use & read and may be replaced with any Fishnet Message-compliant program in any language runnable on a standard Debian distro.
This -compliant application is deployed on multiple through a signing key that is the main upgrade authority of the whole Fishnet system. Read more on the security and decentralization aspects .
The Fishnet API is the main program for interacting with Fishnet. It is a REST-based web service that writes and listens to an Aleph Channel dedicated to Fishnet.
Writing requests need to be accompanied by a signature of the request body and the pubkey of the signer for the API to verify its authenticity.
Then, it checks whether the request conforms to the protocol and should be persisted on the Fishnet Channel. If so, it performs all the inserting and updating of messages necessary to reflect the new state and signs these messages with the nodes' keys.
Upon public launch, the signer will be a multi-sig program on Solana, which is in possession of the Fishnet DAO. With this key, it is possible to deploy new versions of the Fishnet APIs & Executor Clusters, as well as configure consensus and redundancy parameters to increase security as a trade-off to increased resource and $ALEPH requirements of the protocol's treasury.
Aleph allows deployed VMs to be immutable. We intend every major LTS version of Fishnet to be just that. The Upgrade Authority finally decides which VMs may write/update Fishnet Messages and configures Consensus Sets as well as deployed API and Executor VMs.
Given these precautions, it is safe to say that we are about to implement a Smart Contract-like protocol on top of Aleph, compatible with any programming language, where the protocol itself can decide how secure it needs to be in order to perfectly balance security/availability and cost.
To increase tampering resistance, a notion called Consensus Sets will be used, which you can read more about .
Executors are where the storage and computation of the data actually happens. Each Executor is linked to a (or a Consensus Set thereof) and receives all slices of data that are contained by its assigned time window. This is part of the undersaturated redundant storage scheme to protect the IP of data owners.
Again, for purposes of availability and tamper-resistance, we can define a Consensus Set for every time window, which will receive the same slice of data and will perform the same computation when requested through Fishnet .
A Consensus Set could be seen as a more advanced type of , which additionally makes sure that the output of the VMs in one Consensus Set is consistent. The parameters for finding consensus and replication of services may be set by the Protocol Upgrade Authority, up next.
