Editing DAO Governance Framework (section)

=== Distributed computing perspective ===
Since a primary DAO is an open permissionless decentralized network, Byzantine resistance is the primary design consideration. Any network node has the ability to spam the network with any information they choose. A Byzantine node cannot be prevented from editing any software it uses before communicating with the network. So a decentralized network's protocols must involve checking every message for consistency and integrity. The only defense against such behavior is to ignore Byzantine messages that don't accurately encumber valuable tokens or to slash the tokens encumbered in a Byzantine message which does encumber tokens.  

For instance, in DGF workflow, we assume every full node in the network behaves in a similar manner to a full client in the Ethereum network. In Ethereum, a full node participates in the distributed computing architecture called [https://ethereum.org/en/developers/docs/evm/ EVM] as follows. The node first downloads the entire history of the blockchain – every transaction (TX), every smart contract (SC), every record of how much ether was submitted to run each smart contract, and every output of every smart contract so engaged. A full node has its own database of the entire collection of all ERC20 (and ERC471, etc.) tokens that have ever been minted and their complete history. A full node refers to this information to determine the validity of every TX request to fulfill a new transaction on the Ethereum network. This means that any Byzantine action is ignored or punished according to protocols that have previously been established by the Ethereum network.

By analogy with Ethereum's EVM flow, in DGF a full node downloads the entire history of the DAO (the Forum) and parses the value of every REP token, in order of creation, by calculating their values according to the changing rules whose history is encoded in the Forum. A record of every successful Validation Pool is required, as well as the rules for what is a successful Validation Pool at the time it was called. For instance, a Validation Pool has a quorum necessary for it to be considered a canonical instantiation that leads to its inclusion in the Forum. The quorum will change as the DAO evolves. The larger and more decentralized that the DAO becomes, the smaller the quorum needs to be in order to maintain security against Byzantine actions.

This counter-intuitive perspective of maximally redundant computation is necessary to maintain the decentralized structure of the network in the inevitable presence of Byzantine actors.