Hard forks, specifications and dispute resolution

Hard forks, specifications and dispute resolution

Different distributed ledger systems often differ in their underlying political philosophies and technology choices. The Ethereum project originally promised to be an "unstoppable application" that can realize "code is law". After an important smart contract was hacked, a debate arose about whether what happened could be described as a hack due to the lack of non-code instructions on what the program was intended to do. The differences eventually led to divisions within the community.

Because FSC contracts are simple zip files, it can easily contain PDF or other format documents describing the actual intent of the contract. There is no requirement to use this mechanism or for these documents to be legally binding. Nonetheless, in the case of financial applications, if disagreements arise, the legal meaning of the contract that contains them is more important than the software implementation that contains them.

It is technically possible to write a non-upgradeable contract. If such a contract governs an asset that exists only on the ledger, such as a cryptocurrency, then this can provide an approximation of "code as law." We leave the discussion of the wisdom contained in this concept to political scientists and reddit. Platform logs in FSC do not have a direct equivalent to a "hard fork" of the blockchain, so abandon the problem transaction chain or fraudulent transaction chain. The only way to do this is to agree outside the band on discarding an entire subgraph of transactions. Since there is no global visibility, this consensus need not include all participants on the network: only those who may have received and processed the relevant transactions. Another consequence of the lack of global visibility is that there is no single point of recording exactly who saw which transaction. Determining the set of entities that must agree to discard a subgraph means correlating the activity logs of nodes.

FSC nodes record sufficient information in logs to ensure that such correlations can be achieved. The platform defines a stream available to anyone to assist in this process. A tool is also provided that can generate "investigation requests" and send them to a seed node. The flow notifies the node administrator that a decision is required, and sufficient information is passed to the node to attempt to persuade the administrator to participate (such as a signed court order). If the administrator accepts the request via the node browser, subsequent jumps in the transaction chain are returned. This tool semi-automatically crawls the network in such a way that it finds all actors that would be affected by the proposed rollback operation. The platform does not participate in determining what types of transaction rollbacks are legitimate, and provides only minimal support for implementing rollback operations beyond locating the parties that must agree.

There are at least two strategies for modifying the ledger once the involved actors have been identified. One is to extend the transaction chain using transactions that simply correct the database so that it matches the expected reality. In order to make this approach possible, smart contracts must be written so that they can be modified arbitrarily outside of normal business logic when the submitted signatures reach a sufficient threshold. This strategy is simple and makes the most sense when the state contains a small number of parties, none of whom have any incentive to leave harmful information on the ledger.

An asset state resulting from theft or fraud will involve participants who will resist all attempts to patch it in the above manner, because they can derive real-world benefits from the time between when the ledger is corrupted and before it is restored to its actual state. For this situation, a more complex method needs to be used, that is, all participants except the uncooperative participants agree to mark the relevant state as no longer consumed or has been spent. This is essentially a limited form of database rollback.