Brainstorming
This commit is contained in:
parent
a48d14905c
commit
c8ce74cf13
|
@ -16,4 +16,78 @@ meaning that it
|
||||||
- includes what the node believes must be included according to the majority view
|
- includes what the node believes must be included according to the majority view
|
||||||
note that with this scheme there be muliple possible valid proposed blocks.
|
note that with this scheme there be muliple possible valid proposed blocks.
|
||||||
|
|
||||||
---
|
In any case, block production will require some form of consensus protocol. (BFT).
|
||||||
|
|
||||||
|
We have to define an algorithm from the perspective of a single node.
|
||||||
|
|
||||||
|
That node will need to make certain assumptions. Let us identify those assumptions.
|
||||||
|
|
||||||
|
- continuity guarantees?
|
||||||
|
- sender identifiability?
|
||||||
|
- it needs to bo possible to verify an asymmetric signature
|
||||||
|
|
||||||
|
This leads us to the storage requirements for a node.
|
||||||
|
|
||||||
|
For a node to exist, it must be capable of at least some temporal continuity.
|
||||||
|
That's what distinguishes a node from a client.
|
||||||
|
|
||||||
|
We want our protocol to involve performing certain kinds of work.
|
||||||
|
|
||||||
|
- Block production
|
||||||
|
- Messaging protocol
|
||||||
|
- In-memory storage
|
||||||
|
- Queryable history
|
||||||
|
- Fast record storage
|
||||||
|
- Archival record storage
|
||||||
|
|
||||||
|
What is common among these?
|
||||||
|
|
||||||
|
- Availability stake represents commitment to perform the specified work
|
||||||
|
- Peers must validate the work product via validation pool
|
||||||
|
|
||||||
|
How can we adapt the following concepts?
|
||||||
|
|
||||||
|
- Business contract interfacing with availability contract
|
||||||
|
- Reputation is minted via validation pools
|
||||||
|
- Reputation is rewarded to validation pool winners
|
||||||
|
- Reputation is awarded to a post in the forum
|
||||||
|
- Reputation is propagated via citations
|
||||||
|
|
||||||
|
In a messaging system, the work is
|
||||||
|
|
||||||
|
- Listening for messages
|
||||||
|
- Receiving messages
|
||||||
|
- Processing messages
|
||||||
|
- Sending messages
|
||||||
|
|
||||||
|
and may include
|
||||||
|
|
||||||
|
- Maintaining context related to incoming messages for the duration of some operation
|
||||||
|
- Performing computations
|
||||||
|
- Storing data
|
||||||
|
- Retrieving data
|
||||||
|
- Performing other actions
|
||||||
|
|
||||||
|
The work of verifying peers in a messaging system is
|
||||||
|
|
||||||
|
- Detecting invalid messages
|
||||||
|
- Successfully defending against DoS attacks
|
||||||
|
- Initiating validation pools?
|
||||||
|
- Voting in validation pools?
|
||||||
|
|
||||||
|
The work of providing a storage service extends that of participating in a messaging system.
|
||||||
|
|
||||||
|
The work of verifying peers work products in a storage network is
|
||||||
|
|
||||||
|
- Periodically querying peers and verifying their responses
|
||||||
|
- Participating in validation pools to police peers
|
||||||
|
- Initiating validation pools
|
||||||
|
- Voting in validation pools
|
||||||
|
|
||||||
|
Governance of a storage network includes
|
||||||
|
tuning post and validation pool timing and other parameters.
|
||||||
|
This can be served via the forum and validation pool,
|
||||||
|
by having the clients agree on an interpretation of the forum,
|
||||||
|
such that clients can derive from forum posts, at least some operating parameters.
|
||||||
|
It may even be possible to use the forum to provide the client code itself,
|
||||||
|
or tools for generating such code.
|
||||||
|
|
Loading…
Reference in New Issue