forum-logic/notes/chain.md

47 lines
2.1 KiB
Markdown
Raw Normal View History

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.