-
Notifications
You must be signed in to change notification settings - Fork 5
Ontology
The architecture of Spore consists of 9 elements:
- API
- Chain
- Mining
- Code
- Clocks
- Embedding
- Mesh
- Projector
-
Versioned API replaces an execution engine and execution is divided from validation so that nodes can specialise with their required capabilities (latency, storage, connection speed, network locality) to implement other APIs.
-
The central chain only stores its primary fungible tokens and checkpoint type information for the other APIs that are added to the network, which each use storage access strategies that fit their use case.
-
Miners dig not only the core network token (DUO) but tokens that grant a number of uses for a given service in the network. There is also tokens that:
-
grant the right to execute transactions
-
grant the right to publish blocks
-
grant the right to vote on accepting new protocols into the chain
These tokens will be tradeable and a transaction type will exist that records their exchange rates, as well as offer transactions that initiate and set the maker/taker sides of the deal.
The order of block production is fixed through the consensus of active and intending validators, combined with a hash function to select the participants, and is not predictable as it depends on which nodes are recently intending to produce, but is predictable in as far as that set remains unchanged for a series of blocks while the pool remains static.
Executing transactions can be considered to be the identical concept as finalising as used in Tendermint and Polkadot protocols, and cognate to the Flow concept of execution. The transactions are published first, thus committing them, but the execution comes later and ends up as a transaction in the block that follows its consensus discovery process's completion.
-
-
The core of the system is a kind of source-code based distributed software repository shell environment.
Every individual module of the system is implemented in a standalone executable with bindings to a series of logistical coordination libraries, and is distributed and deployed on the network via syncing, compiling and executing the module. Each module exports an API via bindings that app developers use to interact with each app.
-
New APIs added to the network can include their own data storage strategy, and blockchain as such with its immutablity and being append-only does not suit data with a short window of user value. Or they can be other, different distributed protocols with different consensus.
In other words, a wrapper could easily be made that talks Spore on one side and on the other, is, for example, the Bitcoin blockchain. Or equally, run an ongoing gaming tournament leaderboard, which only certifies the final results of matches.
The use of bitcoin can then be transparently mediated and becomes an oracle for the users of the Plan 9 Spore network. The data stored on the ParallelCoin Spore asynchronous blockchain would then be new block hashes, and would log state changes caused by reorgs of the block's chain tip as well, which the other protocol could later use as its own oracle in applications.
All that is required is to glue the protocol's API to the Spore API and the two networks effectively become one, from the Spore network's perspective.
-
Time is a necessary tool in the coordination of a distributed system, but it cannot be relied upon as it is subjective and thus prone to breaking the consensus. As such, instead of requiring timestamps, two process are indirectly regulated by subjective time combined with a limited, small quorum:
-
Issuance of new blocks - to implement this, nodes that are participating in block production all send out beacons to call the creation of the next block as defined by the random number generator combined with the current set of active validation tokens and a declaration of intent message that says a given token has an active node available.
When a node's clock says it's time for the next in line, it starts making the new declaration/calling. The node must get its new block to the majority of its peers before the deadline. Thus, the clock matters, but we make a fuzzy edge on it that relegates the time to a subjective, network-created consensus, smooth instead of discrete.
-
Issuance of tokens - The base currency unit, DUO, by a subjective time quorum computes a difficulty adjustment, the precision is 1 second so the network favours a cluster of nodes that can make the message dialogs that are required. The new tokens would be issued at a fixed amount, with a steadily increasing duration between them to enforce an exponential decay, flat issuance rate over time.
The exact second they should appear is consensus, and when nodes are within 500ms of each other they will all agree on the difficulty target for the next block. By this, simply widening the variance threshold, the claims of time as used in most distributed protocols are not even made, simply the network finds its agreement as it is synchronised to be able to do, and seeks to maintain at over 2/3 majority.
If it is sufficiently synchronised then the value that forms this majority in the quorum becomes the next target, and it goes in the current block. So this is an active, gossip based consensus about time, and should work given the right time limits combined with the latency properties of the network. To minimise falling below quorum requirements, thus follows a third:
-
Non-consensus median time seeking - Nodes will keep and constantly check to update each other's time and adjust their own to reach the median of samples. By doing this, no matter how the topology and participants changes, progressively, in the network, the network's synchrony will seek towards the median of participants at any given time. Timestamps are always subjective and as good as lies, but the consensus is the same thing but agreed, and by being agreed becomes sufficient to regulate the time-related activity of the network.
Outside of these three areas, and in these two areas only indirectly through a preagreed quorum used to trigger both types of events, time is nowhere stored on the chain. This is an asynchronous chain and does not require a central clock to progress and the central clock cannot be exploited to break the network, causality is supreme over subjective claims. The only failure mode in these is from an operating publisher failing to meet the quorum defined deadline. Even when clocks are out of sync, event times are so short that time skew is not at play. If a node hears a message 'time is now' and ask any node on the network and you will get a wide variety of nanosecond precision timestamps, but ask them 'when did I send this relative to that' and the nodes will be in a consensus at least at the millisecond level, but divergent as far as the nodes in quorum are slightly different but close enough to agree.
-
-
The network will use multicast, bluetooth and ad-hoc connections over open wifi hotspots when it can discover peers, in addition to internet connections, and in severe cases of network partitioning, where nodes are isolated from the rest of the network, such as a shutdown or loss of the outbound connections from a location, the network spawns a temporary chain to store the partition history, and then when it regains connection the nodes attempt to reconcile the transactions into the record, as payments only depend on a valid prior transaction input or coinbase.
Further, this protocol, combined with a later VPN protocol addition, will enable toll charged, but privacy protected access to the network from any node (unlike Tor, there will be no 'outside' only the oracles of attached peer protocols).
-
In addition to protocols that certify on it, the network can function to simply act as a gateway to other protocols, if those protocols provide interfaces to use them. Part of this goes back to the foundation of the source-based distributed software repository, which allows such glue applications to be built that implement interface views for a back-end that processes the requests through the UI. Fast, programmable and secure network-projectable interfaces are well used today but written as though a human is ever going to audit everything that goes through it. With everything between machines in binary, a factor of more than 3, up to 5 times performance in terms of messages per kilobyte of traffic.
-
Modular, embeddable network-transparent interface running native on all platforms that are easily added to prior CLI-only interfaces that have been extended to become shell executables with the Spore protocol shell libraries. This is as to replace the mess of javascript/xml derived encodings for network interfaces, and place the workload where it suits the use case better, and in binary, so it is both simpler and less liable to have vulnerabilities caused by flaws in the language processing systems at runtime.