dao-governance-framework/forum-network-node/forum.md

Goals

• Enable each individual to express their values by taking actions in the system.
• Enable a group to arrive at a decision through a process of deliberation.
  • Reward participants in the deliberation process.
• Enable participants to post contributions for review.
  • Also enable discussion during this review process, a.k.a. Enable participants to post comments on the review and on other comments
• Enable participants to submit arbitrary posts that stand alone or that reference other posts
  • This correctly implies recursion.
  • Since we don't want loops, we want a DAG (directed acyclic graph).

Requirements

Use Cases

• Outsiders can submit work requests via the Business contract
  • Includes fees
  • Incoming request can be reviewed and approved by validators
  • Adds a post to the forum
  • Assigns the work request to an associate, via Availability contract
• Associate can submit their work results via the Business contract
  • Adds a post to the forum
  • Associates can carry out discussions on the forum by adding new posts.
    • Each post can attribute reputation for or against other posts
    • Each post should be validated by associates.
  • Eventually a formal vote should occur, in the context of the Business contract. If the votes passes, reputation should be awarded to the following:
    • associate who submitted the work
    • associates who voted in favor of the post
    • associates whose comments in the discussion earned reputation
• Associates can submit new posts to the forum, outside of any existing post or work request
  • Each post should be validated by associates
  • These can be referenced by future posts, thereby gaining or losing reputation
  • Reputation awards are only distributed when posts are later referenced in a fee-generating discussion

Storage Requirements

• Run-time operational data
  • Active sessions
  • Possible cache of on-chain data to expedite look-ups
  • Subscribe to updates?
• Archival data
  • Forum posts and their contents
  • This is needed in order to display forum contents to clients, as well as to compute reputation awards when submitting a batch of forum results to the forum validator contract.

Messaging Requirements

Contracts

Validator Contract

How generic do we want our validator contract to be?

So far, what I've thought of:

• Points to a forum post.
• Off-chain computation provides reputation effects arising from the forum attribution DAG.
• Network nodes function as voters here, to vote on the result they believe is correct. This decision is expected to be determined by the forum client software. The forum contract must include provision for tracking the forum client post with the highest reputation. A new forum client post would include reputation stake against the previous version, and if Like all governance decisions and perhaps many other kinds of decisions, there should be a period of deliberation where participants may express their opinions. At some point it will transition to a formal vote. This will occur when the off-chain network nodes decide to cast formal votes.

Network Node Contract

• Should require staking reputation to add a new network node
• Should require vote by validation pool to add the new network node
• Should allow vote by validation pool to remove a network node

Options for architecture of off-chain forum components.

1

Use the following components:

• Existing storage network
• Existing messaging network
• New forum network nodes

Effects of this arrangement:

• Pro: Minimize storage and network requirements for the individual network nodes, since they won't need to talk to each other directly.
• Pro: Gains benefits of whatever features the chosen storage or messaging systems provide.
• Con: Adds infrastructure costs that must be managed.
• Con: Adds requirement to implement integration with chosen storage and messaging systems.

2

Use the following components:

• Existing storage network
• New messaging network
• Network nodes talk to each other directly

Effects of this arrangement:

• Pro: Reduce messaging infrastructure costs by implementing this functionality within our own application.
• Nodes can discover each other by reading from the blockchain.
• Nodes can vote for/against each other with regard to their stakes as network nodes. Nodes can gossip amongst each other. Nodes MUST be able to verify peer nodes ownership of reputation tokens. Nodes SHOULD periodically re-verify their local view of the network, with the view that may be accessed on-chain.

Notes:

• Since we need our application to be publicly networked anyway, to interact with user agents, it's not asking a huge amount for them to communicate amongst one another.

3

Use the following components:

• New messaging network
• New storage network

Effects of this arrangement:

• Pro: Integrity of storage can be policed by reputation staking

Notes:

• We would have to choose a consensus algorithm for our data storage, or adopt an existing self-managed solution

---

Questions

How much on-chain?

Just hashes? Any full content?

What forum storage?

IPFS? Filecoin? Arweave? CouchDB? Custom?

If we use existing/separate networks for storage and/or messaging, how do we police them? If they mess up our data, whose reputation is staked? Perhaps this is implicitly covered by the Validator voting, where off-chain results are compared. We may want to support multiple storage options. No matter where archival storage occurs, stored data can and should be verified using hashes stored on-chain. Nodes should only write to the archive AFTER voting on results. In the worst case, if archived data loses integrity, it will prevent the forum from processing new transactions. If enough network nodes could agree on a strategy to remediate the data, it might be possible to recover somewhat gracefully. This would depend on the nature and extent of the damage. The last resort would be to initialize a new forum and abandon the old one. While this would be disruptive to continuity of operations for the DAO, it would not alter on-chain reputation holdings.

What forum messaging?

ZeroMQ? RabbitMQ? CouchDB? Custom?

What UI?

The forum contract should serve the forum network node source code. If we only store a hash, we need a secure mechanism for storing and serving the actual code. If we store the full code on-chain, we would also need to document a process for network node operators to obtain the code. For example, by using existing command-line utilities to interface with the blockchain and download the data. If we store the full code off-chain, we would still need to document the process for network node operators to obtain the code. We would also need to make sure that one network nodes are up and running, they help pin the content to IPFS.

The forum network node should then serve the UI to users. This can be served as a web application. Network node will send HTML, CSS, and Javascript to a browser client. The browser client must have an extension that allows it to function as a wallet, and it must be able to provide proof to the forum node, of the user's ownership of reputation tokens.

This can be accomplished as follows:

1. Web client prepares a message (probably using Casper Signer browser extension). Message includes:
   • Public key
   • Nonce
   • Signature
2. Forum node verifies the signed message.
3. Forum node checks on-chain reputation for the given public key.
4. Forum node authenticates the client's HTTPS session.

From there, the forum node should be able to take actions on behalf of the client. Most of these actions will occur initially within the off-chain context. Eventually however, the results of the actions should be encoded in an on-chain validation vote.

The above step 3, check on-chain reputation for given key, may be prohibitively expensive. Here's a way we might deal with that. When the forum node receives the signature from the client, we can store it along with the data representing other forum activities; we can provisionally accept the offered public key from the client, and use it for the purposes of computing reputation effects from forum activities. It could be verified asynchronously. If it turns out to have an issue, however, then we would have to remediate our results before finalizing. Here's another approach. Each client will need to pay a small fee to register with the forum. This would cover the cost of the on-chain transaction which is needed in order for the forum node to verify the client's reputation. Once verified, the forum will store the client's public key. The client will then be able to authenticate with the off-chain forum network. Certain actions in the forum will involve an associate staking reputation. The plan is for the off-chain network to keep track of these actions, and periodically vote on-chain to enact their results. In order for these reputation stakes to be realized on-chain, the Forum Validator Contract must empowered to apply the resulting reputation effects. Otherwise, the user agent would need to engage directly with the blockchain.

How shall we fund the forum nodes to deploy the necessary calls to smart contracts?

Maybe it should be possible to submit a fee in order to fund a given forum node, and thereby to gain some reputation, and thus receive a share of the fees that the DAO earns. This would also suggest the need for a votable parameter to tune the proportion of these rewards.

Should network node contract voters consist of network nodes, or voting associates?

Network nodes should be resistant to DOS attacks by restricting white-listed peers to the list obtained from the network node contract on-chain. But what if a whitelisted node starts misbehaving? A network node that notices a problem with another network node can:

• Locally graylist or blacklist the offending peer.
• Attempt to notify its human operator, who may then cast an on-chain vote against the offender.
• Attempt to notify its network peers, who may then graylist or blacklist the offending peer.
• Automatically cast an on-chain vote aginst the offender.

Let's consider the possibility of nodes notifying each other of problematic behavior of other nodes. What if a bad node sends messages to its peers attempting to gray/blacklist a good node? This suggests that each node should listen for such messages from peers, but should require some number of them before taking action. Perhaps the degree of graylisting can build up with additional reports from other peers.

It should be expected that people will attempt to attack the network nodes. If we enforce whitelisting by reputation stakes via on-chain network node contract, we raise the bar considerably for a successful attack. Remaining threat models:

• A reputation holder may attempt to act against the interests of the DAO.
• A supply chain attack may occur against the network node or user agent
• A man-in-the-middle attack may occur between network nodes, or between user agents and network nodes
• A network node may be compromised.
• A user agent may be compromised.

Among these threats, the supply chain attack against the network node is the most severe. The other threats are limited because individual nodes, clients, or accounts must be compromised one by one. But a supply chain attack may compromise many nodes, clients, or accounts. Therefore, securing the supply chain is a top priority for this system.

What's the desired timing of the process to initiate a new network node?

If the initiator already has reputation available to stake, maybe the process shouldn't take very long. However, it's an action with serious repercussions. If network nodes can be added quickly, then anyone in control of a disproportionately large amount of reputation for whatever reason, could potentially quickly add a fleet of new network nodes and execute a 51% attack on the forum. So, on the order of hours to days seems reasonable to me. Also the answer may depend on the current number of network nodes. When there are more, it will make sense to add them in batches, and it might be nice to expedite that process to an appropriate degree. On the other hand, there may not be a legitimate value in adding many new network nodes in the same physical location. If they're going to be spreat out in space, their activation might as well be spread out in time.