Define any rule
Reading time: 12 minRules: what can be defined?
The key feature of the Axone protocol is the ability to define rules within its ecosystem. The term "Rules" forms the backbone of the protocol, governing how off-chain digital resources like datasets, algorithms, storage, and computation resources are shared and managed. These rules define the parameters and conditions under which resource sharing and interactions occur. Understanding the scope of what can be defined within these rules is crucial for harnessing the full power of the Axone protocol.
A zone is a conceptual framework defined by a set of rules, within which the recognized digital resources are compatible with these rules, considering the associated consents. A resource is not attached to a zone. The recognition of resources within a Zone relies on the dynamic evaluation of the conformity of the rules and consents of the resources.
The Axone protocol enforces rules for governance and consent. When users want to do something in a Zone (launch a workflow to create new indicators or train an AI model, for instance), the protocol checks if it's allowed based on the rules. This decision considers the current situation, as blockchain rules and digital resources constantly change. From a computer science perspective, the challenge is dealing with complex logic involving rules, such as hierarchy, inconsistency, and dependency. To handle this, the Axone protocol ensures a secure and reliable way to interpret rules in a decentralized manner. The rules in each Zone and the consent attached to a resource determine if a user's action is permitted. It's essential to remember that this assessment also considers the evolving state of the blockchain at the time of the request.
- An Identity (human or bot) wants to interact with a Zone
- The Zone asks the dedicated smart contract if it's possible given the context and all the involved rules
- The protocol employs logical inference to resolve matters based on the state of the blockchain
- The protocol yields a modality as a response, such as "prohibited", "permitted", "possible", and so on. Depending on the answer, the execution process could start.
What kind of rules can be defined?
1. Defining Access Permissions
One fundamental aspect of Axone rules is the ability to define access permissions. Through these rules, you can precisely outline who has the right to access specific off-chain resources. Whether granting read-only access to certain data or complete control over a particular resource, Axone empowers users to tailor access permissions according to their unique needs.
2. Resource Utilization Policies
Axone allows users to establish resource utilization policies beyond simple access permissions. This involves defining how shared resources can be utilized, ensuring optimal efficiency, and preventing misuse. Whether specifying the duration of resource access or setting usage quotas, Axone rules provide a flexible framework for resource management. For example, users can define temporal and spatial constraints for resource sharing. This means you can set rules that dictate when specific resources are available, creating dynamic access schedules. Additionally, spatial constraints enable the restriction of resource access based on geographical or network-specific parameters.
3. Business models
Each zone can define how value is created and distributed among participants. This could range from straightforward transaction-based models to more complex, performance-based incentives.
4. Dynamic Rule Updates
The Axone protocol acknowledges the dynamic nature of resource management. Rules can be updated in real-time, enabling users to adapt to changing requirements seamlessly. This dynamicity ensures that Axone remains responsive to evolving scenarios, providing a future-proof solution for off-chain resource orchestration.
5. Inter-Rule Relationships
Axone rules are not isolated entities; they can interact with one another. Understanding and defining inter-rule relationships is a powerful aspect of Axone's flexibility. For example, you can establish dependencies between rules, ensuring that certain conditions must be met before others come into effect.
The ability to define rules is a pivotal feature of the Axone protocol, offering an unprecedented level of control and customization. By leveraging these rules, participants can create diverse applications and ecosystems, each with unique governance and operational dynamics. This flexibility is central to Axone's vision of fostering a decentralized, collaborative, and innovative digital resource environment.
Prolog: Turing complete logical and declarative programming language
In the vast landscape of programming languages, Prolog stands out as a formidable tool. And in the realm of Axone, it plays a pivotal role in shaping the logical and declarative aspects of the protocol. Prolog's significance lies in its ability to handle complex logical scenarios, making it a powerful choice for the dynamic environment of the Axone protocol.
1. The Essence of Prolog
Prolog, short for "Programming in Logic," is a unique programming paradigm that utilizes logical inference and declarative statements. Unlike traditional imperative languages, Prolog focuses on describing relationships and rules rather than explicit step-by-step instructions. This makes it well-suited for expressing complex relationships and solving intricate logical problems, precisely the challenges faced in Axone.
2. Turing Completeness
One of Prolog's notable features is its Turing completeness. This term signifies that Prolog can, in theory, compute anything computable by other programming languages. This attribute is essential for Axone, as it ensures that the logical and declarative programming capabilities provided by Prolog can address the diverse and evolving challenges presented by combining multiple resources and rules.
3. Declarative Programming in Action
In the context of Axone, Prolog's declarative nature is a boon. Users can specify what they want to achieve, and Prolog handles the intricate task of determining how to achieve it. This provides a clear and concise way to express the governance and consent rules governing resource interactions.
4. Logical Problem Solving
The dynamic and evolving nature of Axone's rules necessitates a robust logical problem-solving capability. Prolog excels in this arena by employing a resolution-based inference engine, allowing it to navigate through complex relationships defined by rules. This becomes crucial when resolving issues of hierarchy, inconsistency, dependency, and conflict resolution in access permissions and resource utilization.
5. Decentralized Interpretation
In the Axone ecosystem, where decentralization is a crucial principle, Prolog is integrated into an on-chain module and serves as a trustworthy interpreter of rules. With its established rules, each Zone can leverage Prolog to determine the permissibility of a user's actions. This decentralized interpretation ensures that the governance and consent rules are applied consistently and reliably across the network.
6. Prolog in practice
Here are some fundamental concepts and basics of the Prolog language:
-
Declarative Style: Prolog is a declarative language, meaning that you specify what you want to achieve rather than how to achieve it. Programs in Prolog describe relationships and rules rather than a sequence of steps.
-
Logic Programming: Prolog is a logic programming language. It is based on the principles of first-order logic, where statements are represented as logical predicates.
-
Facts and Rules: Prolog programs consist of facts and rules. Facts are statements about the world, and rules define relationships and conditions. These are the building blocks for creating a knowledge base.
% Fact
% John likes pizza.
likes(john, pizza).
% Rule
% X is hungry IF X likes pizza.
hungry(X) :- likes(X, pizza).
- Predicates and Clauses: In Prolog, statements are expressed as predicates. Predicates consist of a function (name) and arguments. Clauses are the combination of facts and rules.
% Predicate
likes(john, pizza).
% Clause (fact)
father(john, jim).
% Clause (rule)
sibling(X, Y) :- father(Z, X), father(Z, Y), X \= Y.
- Variables: Prolog uses variables to represent unknown values. Variables are denoted with a capital letter or an underscore.
% Variable
% John likes X.
likes(john, X).
- Queries: Prolog is interactive, and users can query the knowledge base. The system will attempt to find values for variables that satisfy the given conditions.
% Query
% What does John like?
?- likes(john, What).
- Backtracking: Prolog uses a backtracking mechanism to explore alternative solutions. If a query fails, Prolog will backtrack and explore other possibilities.
% Backtracking example
% The following rule defines a family relationship.
parent(john, jim).
parent(john, ann).
parent(jim, tom).
% Query: Who is Tom's parent?
?- parent(X, tom).
% This will return X = jim, and upon backtracking, X = john.
- Recursion: Prolog supports recursion, allowing functions to call themselves. Recursive structures are common in Prolog for expressing relationships that involve repetition.
% Recursive rule for factorial
factorial(0, 1):-!.
factorial(N, Result) :- N > 0, Prev is N - 1, factorial(Prev, PrevResult), Result is N * PrevResult.
- Cut Operator (!): The cut operator controls backtracking. It prunes the search space and commits Prolog to the choices made.
% Cut operator example
likes(john, pizza).
likes(john, sushi).
% Query: Does John like pizza?
?- likes(john, pizza), !.
These are some of the basic concepts of Prolog. Its emphasis on logic and declarative programming makes it well-suited for rule-based systems, knowledge representation, and artificial intelligence applications.
As we progress through the Axone Academy, the role of Prolog becomes increasingly apparent in enabling a Turing complete, logical, and declarative approach to managing the intricate rules that define the protocol. Join us on this journey as we explore the depth of Prolog's capabilities within the dynamic landscape of Axone.
Resource's consents
In the intricate web of the Axone protocol, the heartbeat of interaction lies within the rules governing each resource, also called consents. Understanding how these rules are defined and implemented is crucial for harnessing the true potential of Axone's off-chain resource sharing.
1. Defining Resource-Specific Rules
Every resource within the Axone ecosystem comes with its consent, a set of rules intricately defining how it can be accessed, utilized, and shared. These rules act as the blueprint for the resource's behavior, outlining the conditions under which it can be interacted with. Whether it's data, computational power, or any other off-chain asset, the rules are the guiding principles for their governance.
2. Access Permissions and Restrictions
At the core of resource consents are access permissions and restrictions. Axone allows resource owners to precisely dictate who can access their resources and under what circumstances. This includes specifying read or write permissions, setting limitations on the duration of access, and defining the geographical or network-based constraints for interaction. Such fine-grained control ensures that resource owners maintain sovereignty over their assets.
3. Resource Utilization Policies
Beyond mere access, Axone resource consents extend to resource utilization policies. Owners can define how their resources should be utilized by setting usage quotas, determining the conditions for resource sharing, or specifying the acceptable purposes for interaction. These policies contribute to the efficient and controlled utilization of resources within the decentralized Axone network.
4. Dynamic Rule Adaptation
Consents in Axone are not static; they adapt dynamically to the changing needs of the ecosystem. As conditions evolve, resource owners can update rules in real-time, ensuring that their assets remain responsive to the ever-shifting landscape of off-chain resource sharing. This dynamic adaptability is a key feature that aligns Axone with the fluid nature of decentralized networks.
5. Rule Interdependencies and Conflicts
Given the interconnected nature of resources and their rules, Axone acknowledges the potential for interdependencies and conflicts. The hierarchy of norms refers to the hierarchical structure of rules within the Axone governance framework. It establishes the order of precedence among the different norms so that a higher norm prevails over a lower standard. Then, the rules of a Zone prevail on the resource consent (see technical doc).
6. Transparency and Auditing
Axone places a premium on transparency in resource governance. Resource consents are designed to be transparent and auditable, allowing users and stakeholders to understand how each resource is governed. This transparency fosters trust and contributes to the overall security and accountability within the Axone ecosystem.
7. Let's practice
Let's consider a simple example of rules written in Prolog for a hypothetical resource-sharing scenario within the Axone context. In this example, we'll create rules for granting access to a specific dataset based on user roles and temporal constraints.
% Define roles
role(admin).
role(user).
role(guest).
% Define users and their roles
user_role(john, admin).
user_role(susan, user).
user_role(bob, guest).
% Define access rules based on roles and time
access_rule(admin, Dataset, _):- dataset(Dataset).
access_rule(user, Dataset, Time):- dataset(Dataset), current_time(Time), Time < 18.00.
access_rule(guest, public_data, _).
% Define the dataset
dataset(confidential_data).
dataset(public_data).
% Simulate the current time (for illustration purposes)
current_time(15.30).
% Example queries
% Query: Can John access the confidential_data dataset at the current time?
% Result: Yes, because John is an admin, and there's no temporal constraint for admins.
?- user_role(john, Role), access_rule(Role, confidential_data, Time).
% Query: Can Susan access the confidential_data dataset at the current time?
% Result: Yes, because Susan is a user, and the current time is before 18.00.
?- user_role(susan, Role), access_rule(Role, confidential_data, Time).
% Query: Can Bob access the confidential_data dataset at the current time?
% Result: No, because Bob is a guest, and the dataset is confidential with no specified temporal constraint for guests.
?- user_role(bob, Role), access_rule(Role, confidential_data, Time).
In this Prolog example, we define roles (admin, user, guest) and associate users with roles. Access rules are determined based on roles and, in some cases, temporal constraints. For instance, admins have unrestricted access to any dataset, users have access before 18.00, and guests can access to the public_data dataset without time constraints. We define two datasets (confidential_data and public_data). The current time is simulated to illustrate temporal limitations. Example queries demonstrate how Prolog can be used to check if a user has access to a specific dataset at the current time based on the defined rules. Note: The Axone SDK contains templates of governance rules that you can use and adapt to your needs.
As we delve deeper into the Axone Academy, understanding the intricacies of resource rules becomes paramount. These rules serve as the backbone of the protocol, ensuring that off-chain resources are governed with precision, flexibility, and transparency. Join us as we unravel the complexities of resource rule management within the dynamic landscape of Axone.