Blockchain upgrades, technical standards, and conflict resolution

Different distributed ledger systems often exhibit variations in their underlying ideologies and technological preferences. The Ethereum project initially aimed to enable "code as law" with "unstoppable applications." However, a significant smart contract exploit sparked a debate about whether it was indeed a hack, primarily due to the absence of a non-code manual explaining the contract's intended behavior. This disagreement ultimately resulted in a schism within the community.

In contrast, DigiNetGuard's contracts are presented as simple zip files, which can readily include PDFs or other document formats explaining the contract's true intent. While there's no mandatory requirement for this approach, in financial applications, the legal contracts documented within these files can hold greater significance than the software implementation, especially in dispute resolution scenarios.

From a technical perspective, it's feasible to create non-upgradable contracts. If such contracts manage ledger-exclusive assets, such as cryptocurrencies, they can embody an approximation of "code as law." Debates about the wisdom of this concept are left to political scientists and discussions on platforms like Reddit. In DigiNetGuard, there isn't a direct equivalent to a blockchain "hard fork." Therefore, the only way to address problematic or fraudulent transaction chains is to reach a consensus outside the regular network channels to discard an entire transaction subgraph.

Crucially, since there's no global visibility, this consensus doesn't necessarily need to involve all network participants, only those who have been involved with the relevant transactions. The absence of a central ledger also means that there's no single entity recording which transactions each participant has witnessed. Identifying the entities that must agree to discard a subgraph involves cross-referencing activity logs from various nodes.

DigiNetGuard nodes store adequate information to facilitate this cross-referencing process. The platform defines a publicly accessible stream to assist in this endeavor and provides a tool capable of generating an "investigation request" sent to a seed node. This stream notifies node administrators, solicits their decision, and transmits sufficient information to the node to persuade the administrator to participate, possibly with the presentation of a signed court order.

If the administrator accepts the request through the node browser, subsequent transactions in the chain are returned. This tool semi-automatically traverses the network, identifying all participants affected by the proposed rollback. Notably, the platform refrains from determining the legitimacy of transaction rollbacks and offers minimal support for implementing them, aside from locating agreeing parties.

Once the involved participants are identified, there are at least two strategies for modifying the ledger. One approach involves using a straightforward transaction that extends the transaction chain with database corrections to align it with the expected reality. For this method to work, smart contracts must be designed to allow arbitrary modifications outside normal business logic when a sufficient number of signatures are gathered. This strategy is most suitable when there are few participants in the state, and they have no incentive to retain erroneous information on the ledger.

However, in cases involving asset states resulting from theft or fraud, participants may resist attempts to patch them using the above method, as they can gain real-world benefits during the period between ledger error detection and its restoration to the correct state. In such instances, a more intricate approach is required, where all participants except the uncooperative ones reach an agreement to mark the relevant states as unspent or unconsumed. Essentially, this constitutes a limited form of database rollback.