Decentralized Architectures

We envision a world where software systems are fundamentally different than the software systems of today because they respect the rights of citizens, communities, and corporations to maintain their own models of the world, leading to potential disagreements. Such systems that recognize and embrace disagreement are decentralized software systems. — Rohit Khare

Concepts

Centralized systems have a single, exclusive agency (authority) that can modify or take action. Others may use or change information, but must do so through the agency. Even two-phase commit protocols for 'distributed' databases rely on a centralized transaction monitor.

Distributed systems have multiple (agreeing) agencies that share the same goals and that can each modify or take actions; because they share the same goals, they form consensus. Distributed systems must deal with the issue of latency:

Latency introduces uncertainty. Latency refers to the physical limitations of communication between geographically distributed parties, such as propagation delay, bandwidth, and disconnection. Latency introduces uncertainty because of an inability to keep every party informed of current values in a model, since by the time a party is updated, the model may have further changed.

Decentralized systems have multiple (disagreeing) agencies that have different, and possibly conflicting, goals. Unlike centralized and distributed systems, decentralized systems lack a central agency or a collection of agreeing agencies. Decentralized systems must deal with the issue of agency:

Agency introduce disagreement. Agency refers to the individuals and organizations that ultimately own and operate the computers that software runs on. Multiple, disagreeing agencies makes simultaneous agreement impossible due to the different (possibly conflicting) goals and interests of each agency.

Open, decentralized systems do not regulate which agency can participate in the system, leaving the system vulnerable to agencies claiming to be trustworthy that actually have malicious intent. In such systems, peers must autonomously determine which parties are trustworthy, and which are not.

Trust plays a central role in decentralized systems. [Grandison and Sloman, 2000] defines trust as the firm belief in the competence of an entity to act dependably, securely, and reliably within a specified context. A malicious peer could delay, prevent, or undermine the goals of other peers depending on whether they place trust in its services.

Techniques

Minimize latency by using asynchronous notifications of resource changes. This achieves simultaneous agreement as quickly as theoretically possible.

Minimize latency by routing directly to relevant agencies. This reduces unnecessary network delay introduced when routing data through linear proxy chains that are only interested in data flowing in one direction and do not modifying data data flowing in the other.

Prevent "lost updates" by delegating to a mutex lock. This allows an agency to modify a resource without accidentally overwriting updates of other agencies, achieving Atomicity and Consistency of the ACID properties.

Use estimation when agreement cannot be achieved. When issues of latency and/or agency make simultaneous agreement impossible to guarantee 100% of the time, we can add intelligence to the infrastructure to estimate current values.

Use trust relationships to mitigate decentralized security threats. Incorporating trust into decentralized applications allows each agency to function in the presence of agencies with conflicting goals or agencies with malicious intent.

Styles/Protocols

• ARRESTED - Asynchronous, Routed REST with Estimation and Decentralized Decisions - An extension to the REST architectural style that adapts it for use in decentralized systems.
• PACE - Practical Architectural approach for Composing Egocentric trust - An architectural style that provides comprehensive guidance on addressing many different decentralized security threats. It supports different trust models, which determine trust based on different categories of information.

Tools

• PACE reference architecture - used to implement decentralized auctioning, file-sharing, and common-operational picture prototypes

Ph.D. Dissertations

• Architectural Styles and the Design of Network-based Software Architectures - Roy T. Fielding
• Extending the REpresentational State Transfer Architectural Style for Decentralized Systems - Rohit Khare

See Also

• Some definitions of trust and of decentralized trust management terms

• Architectural Support for Trust Models in Decentralized Applications (ICSE 2006)
• An Architectural Approach for Decentralized Trust Management (IEEE Internet Computing 2005)
• Extending the Representational State Transfer (REST) Architectural Style for Decentralized Systems (ICSE 2004)