4.7 Hard forks, specifications, and dispute resolution

Different distributed ledger systems often vary in their underlying political philosophies and technological choices. The Ethereum project initially promised to enable "code as law" with "unstoppable applications." However, after a significant smart contract was hacked, there was debate over whether the event could be described as a hack, due to the lack of a non-code manual explaining what the program was intended to do. The disagreement eventually led to a split within the community.

Because DeFi Mall contracts are simply zip files, they can easily include PDFs or other format documents describing the actual intent of the contract. While there's no requirement to use this mechanism or for these documents to have legal force, in financial application cases, the legal contracts they contain can be more important than the software implementation in case of disputes.

Technically, it's possible to write a non-upgradeable contract. If such a contract manages an asset that exists only on the ledger, like cryptocurrency, it can provide an approximation of "code as law." The discussion of the wisdom implied by this concept is left to political scientists and Reddit. There's no direct equivalent to blockchain's "hard fork" in DeFi Mall, so the only way to abandon a problem transaction chain or a fraudulent transaction chain is to reach an out-of-band consensus to discard a complete transaction subgraph.

Since there's no global visibility, reaching this consensus doesn't need to include all participants in the network: just those who may have received and processed the relevant transactions. The lack of global visibility also means there's no single point that accurately records who has seen which transaction. Identifying the set of entities that must agree to discard a subgraph means correlating activity logs of nodes.

DeFi Mall nodes log sufficient information to ensure such correlation is possible. The platform defines a stream accessible to anyone to assist this process. It also provides a tool that can generate an "investigation request" and send it to a seed node. The stream notifies node administrators, requests a decision, and transmits sufficient information to the node to attempt to persuade the administrator to participate (such as a signed court order).

If the administrator accepts the request through the node browser, subsequent hops in the transaction chain are returned. This tool semi-automatically crawls the network, identifying all participants affected by the proposed rollback. The platform does not participate in determining what types of transaction rollbacks are legitimate and provides minimal support for implementing rollbacks, beyond locating the agreeing parties.

Once the involved participants are identified, at least two strategies can be used to modify the ledger. One is to use a simple transaction that extends the transaction chain with database corrections, making it conform to the expected reality. For this method to be possible, smart contracts must be written such that they can be arbitrarily modified outside of normal business logic when a sufficient threshold of submitted signatures is reached. This strategy is straightforward and makes the most sense when the number of participants in the state is small, and they have no motivation to leave harmful information on the ledger.

For asset states arising from theft or fraud, the included participants will resist any attempt to patch them using the above method, as they can gain benefits in the real world during the discrepancy between the ledger's error and its restoration to actual state. For such cases, a more complex method is needed, where all participants except the uncooperative ones agree to mark the relevant states as no longer consumed or spent. This is essentially a restricted form of database rollback.