A working decentralized network is, in fact, a massive set of microstates spread across a multitude of network participants. Participants use uniform sets of rules and assessments to ensure a uniform interpretation of events and control actions. Due to generally accepted rules, network participants come to a consensus and uniformly interpret controversial situations, minimizing conflicts.

In the simplest form, for example, conditions (code) for verifying the creation of a public channel or posting a message in it - whether the author can publish information, has he paid the required fee, etc.

For different types of services operating on the network, there may be different rules, different payment terms, and so on.

There are two possible approaches to disseminating rules to network participants - hard-coded rules within the software and dynamic rules within the network itself. Let's consider the pros and cons of both approaches.

This approach is convenient for a limited, rarely expandable set of rules. However, it creates two problems. The first problem is that active development involving rule modification requires a new version of the participant's network software for each change. Differences in update speed by participants (and possibly refusal to update) lead to network segmentation and potential collapse. In blockchain terminology, there will be constant partial hard forks. This can result in a situation where some participants miss certain messages or events within the network, while others ignore them due to outdated software. The second problem is that developing new rules requires attracting Calcium node developers, leading to centralized development and hindering the network from living its own life.

Dynamic rules within the network itself are of much greater interest in terms of development dynamics. With this approach, it is sufficient to have a mechanism for publishing new versions and a mechanism for public voting, introducing rules into circulation. In this implementation, the Calcium node still has several primitive, hard-coded mechanisms that do not require immediate updates and autonomously ensure the operation of all new dynamic rules. This solves the problem of rule hard forks, and all participants promptly see the same versions and the moment of entry into force. However, the downside is the need for the community to responsibly approach the selection of rule updates, which requires technical knowledge and programming skills.

In the Calcium network, the second approach is chosen: each node synchronizes a set of dynamic rules from the network's data.

Out of two options for storing rules (each node stores them itself, or rules are stored centrally), the option of centralized storage in the UFO blockchain was chosen.

When a new rule is published in the network, a special format transaction called a SaveData transaction is used for its preservation. It is a normal single (for short data) or double (for long data) UFO transaction, which includes an OP_RETURN output with data (plus a burnt sum), as well as an additional reference output for binding to a global identifier.

Each such transaction contains a small set of service data, which is read by calcium nodes, validated, and applied after publication in the blockchain. The sequence of such data is called a Calcium Command Stream. The global identifiers to which the data is bound are the identifiers of such command streams (Calcium Command StreamID).

If we imagine all SaveData transactions as an infinite magnetic tape, the saved command streams will look schematically as follows:

During the first launch, Calcium nodes scan the blockchain and read the required command streams, validate them, and apply them to their internal state.

Since storing data in the blockchain leads to its "blowing," saving data in it usually causes heated debates. In addition, there is a simple increase in size that falls on the shoulders of those who hold the blockchain themselves.

Based on common sense, it can cautiously be assumed that a blockchain can be used as a database, but only to store in a concise form exclusively those data that represent a certain value in historical retrospect.

If we consider this approach in terms of content generation in the Calcium network, we can assume that, for example, saving the content of a public post (articles in Slabber's terminology) in the blockchain would be irresponsible due to its potentially huge size. At the same time, saving a few tens of bytes of service data that record the fact of creating a channel or article would be a reasonable use of resources.

Thus, with the help of SaveData transactions in the UFO blockchain, Calcium network participants save only small pieces of data that can be used by other users to update and synchronize their states.

As mentioned above, a clear interpretation of the rules by all participants is the key to predictable network operation for each participant. And publishing them in the blockchain allows using the blockchain itself as a mechanism for synchronizing rules among all participants.

What is a "rule"? Essentially, it is a small script executed by a Calcium node within a simple virtual machine. It could be loosely compared to a smart contract, but in fact, it is a decentralized micro-application capable of executing its specific task well.

When it is necessary to evaluate new data received from the blockchain (or other participants), a Calcium node inputs data into the rule and receives an assessment of the validity of what is happening as output.

We deliberately do not describe any specific restrictions and requirements for such rule scripts, as in general, the mechanism is as flexible and expandable as possible. And real limitations can and will be set as the entire ecosystem built on such a mechanism develops.

Any network user can publish an arbitrary new rule or an updated version of an old rule by saving a specialized SaveData transaction in the UFO blockchain. Such action creates a draft of the rule available to all other users. It does not come into effect automatically because a voting mechanism is required to overcome high-frequency rule manipulation and to protect all participants.

The Calcium network is an unlimited set of participants, and normal voting will be susceptible to Sybil attacks. Therefore, voting must be limited by physical resources.

Using mining as a limiting resource does not seem practical because at "low turns," it will be susceptible to manipulation by individual users, and at high loads, it will cause inconvenience to regular users and centralize mining (a vivid example is Bitcoin).

As the main physical resource for voting, the UFO coin itself was chosen. The key point here is that "voting" implies the physical burning of UFO coins by any interested users in favor of the version of the rules they consider ideologically correct.

The new rule (a new version of an old rule) comes into effect no earlier than 2 weeks after publication and provided that 30% more funds have been burned for it than for the previous version. At the time of writing the article, 2 weeks and 30% are conditional values and may change by the time the Calcium-Nodes software is released.

Since there is no centralized entity responsible for controlling the timeline of such a voting, and the entire process of publishing the rule and voting is synchronized through transactions in the UFO blockchain, we get an interesting form of endless voting, where each participant makes a decision on the activation/deactivation of the rule based on the consensus described above.

Network users get a voting model that is physically impossible to complete, as the life cycle of the rule actually includes constant competition with other versions - new and old. It is impossible to prohibit other network participants from continuing to vote for the old version (sending coins for burning), so there are no mechanisms that allow the old version of the rules to be completely eliminated from the game.

This opens up the possibility of rolling back changes through the same voting if a group of network participants does not like the work of the new version. Also, with two competing versions of the rules - the working old and the gaining popularity new - a group of supporters of the old version can continue to vote for the old version, not giving way to the new one.

In the end, any participant in the voting will be limited by the physical amount of UFO coins that they not only own, but are also willing to burn irreversibly in favor of new changes in the network or the support of old ones. Attempts to spam the network with meaningless rules, as well as attempts to "hack" the existing rules, will sooner or later lead to the depletion of the spammer's "coin" resource.

In the established working model of the Calcium network, the group of users who benefit the most from the stable operation of the network will be interested in maintaining the balance and countering the malicious behavior of other users.

In terms of consensus, the Calcium network is based on a very risky but fully decentralized agreement scheme between network participants. The Calcium node software contains a minimal set of rigid constraints, allowing for a uniform receipt and interpretation of work with dynamic rules stored in the UFO blockchain. Any additional logic built on the rules themselves will require significantly fewer changes to the Calcium node software.

The use of burned UFO as a physical limiter in some cases limits the influence of malicious users on the network and the state of consensus between participants.

At the initial stage, such a scheme carries significant risks of "incorrect" launch or network imbalance, but at the same time represents a highly innovative way of building consensus that has not been seen before in other near-blockchain (and even simply decentralized) projects.