Naftaly Minsky Rutgers University

Law-Governed Multi-Agent Systems: From Anarchy to Order Naftaly Minsky Rutgers University “Law is order, and good law is good order” Aristotle, Politics Book 7

Qualification • This talk addresses open (agent) systems, composed of heterogeneous agents, whose membership may change dynamically, and might be very large. • In such system an agent might not know, or trust, the behavior of its interlocutors—and may not even know who they are. • However, in a sense, all large scale systems are open!!

Outline • On the Governance of Software: the nature of laws, and their potential benefits • Law-Governed Interaction (LGI)—a very short overview. • Interrelationship between laws, and their evolution—using a virtual enterprise as a case study. • Methodological observations: the effect of laws on the analysis, design, and evolution of MASs—and on reasoning about them. • Conclusion, and the release of LGI.

Introduction • What is common to the following “multi-agent systems”? • Cars moving through an intersection. • People buying produce in a farmer market. • Flock of birds flying in formation. • Celestial motion • The web • Each is critically based on the existence of a law—i.e., on a principle, actually observed by the agents in the systems, which thus induces a regularity in it. • We employ here the physical law as a metaphor—in other respects the metaphor of social law is more apt for our laws

Examples of “Good” Laws • The laws underlying our example MASs • Moving cars: traffic laws—e.g., “stop at red light” • Farmer market: money cannot be forged. • Flock of birds: ?? • Celestial motion: Newton’s laws • The web: HTML format & HTTP protocol • The benefits of these laws is rooted in the compliance with them—even if approximate.

Some Potential Benefits of Laws • Mutual trust, which facilitates collaboration [the market] • Safety and security[traffic, market] • Simplification: ability to reason in absence of details [celestial motion]. • Lawless open systems cannot be reasoned about. • Robustness: properties that rely on the law alone are independent of system details, thus invariant of changes in them [celestial motion, traffic]

Benefits of Laws (cont) • Laws can impose structure on a system, such as managerial structure, which provides some agents with power over others. • Laws can protect the system against ignorant, careless, or even malicious, agents. • Laws can provide a frameworkfor building a system, for reasoning about it, and for maintaining it. • Just think about how much of our economy depends on the laws governing money.

$ tasks tasks tasks tasks $ $ $ $ $ task $ task $ tasks $ tasks $ $ $ $ $ $ $ $ $ task The Management of a Buying Team—an Example The manager should be able to assign tasks and budget to members of the team; and to change the assignments, dynamically. Buyers should be able issue POs, subject to their assignments Buyers should be able to exchange assignments “To manage, is to monitor, and steer”. Buyers must report to the manager Manager These capabilities should be established by law! Buyers

Making a System Law-Abiding • The difficulty: to be meaningful, a law needs to be observed by everybody subject to it—so, it cannot be localized in a conventional manner. • In social system, laws are established via education, peer pressure, and social enforcement, like police. • In distributed systems, like a MAS: • By manual construction—effective only • if the system is uniform [like birds of a feather], or small enough. • By voluntary compliance (e.g., the web)—effective only • if it is in the interest of everybody to obey this law. • and if the violator cannot damage anybody but himself. • By enforcement

What Should Laws of a MAS be About? • They cannot be about the structure and behavior of the agents themselves—which might be heterogeneous, and unknown—but they can be about the interaction between agents. • Interactions are critical aspect of a system, which do not belong to any particular agent, and thus deserve special attention. • As has been well recognized by the prodigious research on coordination.

Requirements for a Regulatory Mechanism for Software • High expressive power, in particular, laws should be: • Stateful—i.e., sensitive to the history of interaction. • Able to mandate side effects to interactions—in particular, state change. • Proactive—i.e., able to initiate actions. • Decentralizedenforcement, for scalability. • Local formulation of laws—necessary for decentralization of enforcement.

Requirements (cont) • Communality: laws should be able to regulated entire communities—contrary to conventions access-control, which is server-centric. • A given system may be subjected to a multitude of laws, which should be: • able to interoperate. • organized into hierarchies • Laws should be allowed to evolve, in a self-regulatory manner. • All these properties need to be met via a single mechanism—for specifying policies, and for enforcing them.

Conventional Approaches • Conventional approaches for regulating interactions fall into two classes: • Access control, generally focused on security—[not expressive enough, and “server-centric”] • Coordination mechanisms, like Chemical Reaction (Banatre at al.), LO (Andreoli), TuCSoN (Denti & Omicini), EgoSpaces (Roman et al.)—[overly centralized, and unscalable] • These approaches fall short in other ways as well. E.g., they do not support interoperability and hierarchy between policies (laws).

Law-Governed Interaction (LGI)a Decentralized Regulatory Mechanisms • Satisfies all the above requirements. • Inherently decentralized enforcement—although it provides for a whole spectrum between completely decentralized, to completely centralized—as a means for optimization. • Two languages for writing laws—Prolog & Java—with the same semantics. • Easy and incremental deployment.

Overview of LGI (cont) • Efficiency: overhead of 20 – 200 µs. • History and status: • Has been defined in an 1991 paper in the IEEE Tr. on Soft. Eng. • Prototype implementation in 1996. • Beta version of LGI to be released by the end of May 2005, via: http://www.cs.rutgers.edu/moses/

v u m ==> x m P m’ m ==> y y x I S Reference monitor Legend: P---Explicit statement of a policy. I---Policy interpreter S---the interaction state of the community Centralized Enforcement of Communal Policies * The problems: potential congestion, and single point of failure * Replication does not help, if S changes rapidly enough

m ==> y m m v u L L I L I L Move(2) y Su $1 I x I $9 S L Move(2) I actor Sv Moved(2) $3 controller $7 Distributed Law-Enforcement under LGI

controller server controller server I I I I I I m ==> y y x m’ adopt(L, name) L L adopt(L, name) m’’ Deployment of LGIvia a Distributed TCB (DTCB)

The local nature of LGI laws • Laws are defined locally, at each agent: • They deal explicitly only with local events—such as the sending or arrival of a message. • the ruling of a law for an event e at agent x is a function of e, and of the local control state CSX of x. • a ruling can mandate only local operations at x. • Local laws can have powerul global consequences—because of their global purview. • This localization does not reduce the expressive power of LGI laws, • and it provides scalability for many (althouh not all) laws.

E3 P3 E2 E1 P1 P2 PC Governance of Virtual Enterprise(a Case Study) • Consider a coalition C of enterprises {E1,..., En}, governed by a coalition-policy PC---where each Ei is governed by its own internal-policy Pi . • As in: virtual enterprises, supply chains, grid computing, etc.

$1 E3 $1 $1 $1 E2 E1 $1 $1 $1 P1 P2 PC Policies Governing a Virtual Enterprise(an Example) Roles: each Ei should have its director Di(*); and the coalition C a director DC. A director Di can mint Ei-currency $i needed to pay for services provided by Ei and it can giveDC some of this currency A director DC can distributesome of its $i currency among other directors. $i Currency cannot be forged—by anyone! Servers at E1 can send their earning in $1 back to their director A director D2 can distribute its $i budget among agents at its enterprise

The Main Challenges • The flexible formulation of such policies, so that: • they will be consistent, and • their specification and evolution would be manageable. • Enforcement of such policies, and in a scalable manner.

The Compositions Approach… • Given the set {PC , P1,. . ., Pn} of policies. • Construct a set composed policies: {Pi,j = composition (Pi , PC , Pj)} • Provide these compositions to the reference monitor (RM) that mediates all coalition-relevant interactions. • Compositions were studied by: Gong & Qian 96, and by Bidan & Issarny 98, ...

… and its Problematics • It is unlikely for arbitrary, and independently formulated, policies to be consistent—so such composition is likely to fail. • Policy composition is computationally intractable(McDaniel & Prakash 2002)—and, we need N^2 such compositions! • Inflexibility: consider changing a single Pi . . .

The Proposed LGI-based Approach • Instead of creating N^2 compositions (Pi , PC , Pj), we enable each enterprise Ei to create it own policy Pi , subject only to the constraint that Pi would conform to PC • We will then allow Ei and Ej to interoperate, each enforcing its own policy, Pi & Pj respectively

Hierarchy Organization of Coalition Policies PC superior subordinate P1 P2 Pn Pi is defined as subordinate to Pc, as thus constrained to conform to it.

E3 P3 E2 E1 P1 P2 PC Interoperability • Let us focus on the interoperability between E2 and E1

controller controller P1 P2 export(m,y,P1) imported(x,P2,m) m I I CSx CSx x y Cx Cy E2 E1 Authenticated by CA2and CAC Authenticated by CA1and CAC Interoperability (cont.)

Outline • On the Governance of Software: the nature of laws, and their potential benefits • Law-Governed Interaction (LGI)—a very short overview. • Interrelationship between laws, and their evolution—using a virtual enterprise as a case study. • Methodological observations: implications to the analysis, design, and evolution of MASs—and to reasoning about them. • Conclusion, and the release of LGI.

Specification and Design • Law has been part of the initial specification and design of social systems. • The USA has been “specified and designed” by its constitution. • The initial design of a transportation systems, involved the traffic laws • This must be the case for any open systems. • In particular, because roles —like that of a manager—often imply laws. • This was recently “discovered” by Zambonelli at al. about Gaia—in their 2003 paper.

Implementation • Thesis: laws must be part of the system and not just part of its design. • This is chiefly due to the globality of laws, which: • Makes it hard to implement a law manually. • And makes it easy to violate a law, anywhere in a given system. • Being “part of the system” means that the very act of writing the law formally means enacting it. Thus, laws need to be enforced.

Evolution • Evolution of the Code • The existence of a law naturally constrains the code of the various parts of the system, and the evolution of this code. • This is generally a good thing, which bridges the gap between the specification of a system and its code.

Evolution (cont) • Evolution of the laws themselves, involves several issues: • “hot update” of a law, while the community governed by it operates. • How a given law can be changed? • I believe that laws, like the constitution of a country, must be self regulatory—but this is a wide open question. • Who is to be allowed to initiate a valid change of a law, and under which circumstances.

Reasoning • Lawless open systems cannot be reasoned about. • But how does one actually reason about systems governed by explicit laws? • This, very much open, question has two aspects: • How does one reason about a law alone? • How does one combine the knowledge of a law, and of some code (i.e., code of certain agents) to make conclusions about the system?

Conclusion • The idea of laws that governs software is far from new—every programming language imposes such laws. • But laws are critical for open distributed systems—like MASs—and require a fresh approach. • LGI provides one such approach, with an effective, and quite general, middleware to support it.

Conclusion (cont) • A Beta version of LGI is to be released in May 2005, via: http://www.cs.rutgers.edu/moses/ • This release would not include law-hierarchy, and hot-update of laws • Papers about this subject are available through my website: http://www.cs.rutgers.edu/~minsky/ • LGI is very much work-in-progress. There is much work to be done, on both the LGI mechanism itself, and on its various applications and implications. • And I hope some of you will take a look at these issues.

Naftaly Minsky Rutgers University