47 lines
2.1 KiB
Markdown
47 lines
2.1 KiB
Markdown
|
We've considered implementing this validation pool + forum structure as smart contracts.
|
||
|
|
However, we expect that such contracts would be expensive to run, because the recursive algorithm for distributing reputation via the forum will incur a lot of computation, consuming a lot of gas.
|
||
|
|
|
||
|
|
Can we bake this reputation algorithm into the core protocol of our blockchain?
|
||
|
|
|
||
|
|
The structure seems to be similar to proof-of-stake. A big difference is that what is staked and awarded is reputation rather than currency.
|
||
|
|
The idea with reputation is that it entitles you to a proportional share of revenue earned by the network.
|
||
|
|
So what does that look like in this context?
|
||
|
|
|
||
|
|
Let's say we are extending Ethereum. ETH would continue to be the currency that users must spend in order to execute transactions.
|
||
|
|
So when a user wants to execute a transaction, they must pay a fee.
|
||
|
|
A portion of this fee could then be distributed to reputation holders.
|
||
|
|
|
||
|
|
- https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/
|
||
|
|
- https://ethereum.org/en/developers/docs/nodes-and-clients/
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
execution client
|
||
|
|
execution gossip network
|
||
|
|
|
||
|
|
consensus client
|
||
|
|
consensus gossip network
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
cardano -- "dynamic availability"?
|
||
|
|
staking pools -- does it make sense with reputation?
|
||
|
|
what about for governance voting --
|
||
|
|
do we want a representative republic or a democracy?
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
# Protocol brainstorming
|
||
|
|
|
||
|
|
Each node must build/maintain a view of the history and/or state of the "smart contract" operations.
|
||
|
|
|
||
|
|
Nodes must sign messages to each other with asymmetric keys.
|
||
|
|
|
||
|
|
This is intended to be an open network that anyone can join.
|
||
|
|
|
||
|
|
Each node must verify the results reported by other nodes, and themselves report results to other nodes.
|
||
|
|
|
||
|
|
In order to receive payments, the network must solve the same problems that (other) block chains have solved, i.e. must prevent double-spend; must prevent tampering with the ledger.
|
||
|
|
|
||
|
|
Storage may be ranked into tiers, where there is core data essential to the integrity of the ledger; ancillary data that is important or desirable for review of the ledger; and supplementary data that is of variable importants for particular use cases, but does not compose the core fabric of the system.
|