What makes higher-order composition powerful

[erights]

(This came up in internal chat. @katelynsills suggested it should be captured somewhere before it gets lost. Hence this issue.)

There are two features that together make higher-order composition powerful:

1. that the invites are themselves payments that fit within our generic notion of erights. This is normally what we think to highlight.
2. That most of our contracts are generically parameterizable --- that they can exchange any kind of eright without needing knowledge of the specific eright.

AtomicSwap, covered call, and most auctions, are generally parameterizable. Autoswap is not.
Pegasus is currently not, but apparently can be.

[Chris-Hibbert]

I claim that our stronger security claims (due to Zoe and OCaps) make contracts effectively more reusable on our platform than on others. On other platforms it's possible to compose contracts, but you're vulnerable to their errors and malfeasance. On the Agoric chain, Zoe and OCaps make you less vulnerable to those issues. Hence you should feel freer to re-use code you haven't audited on our platform, while you should feel very hesitant about doing the same on other platforms.

[erights]

Good point. It is not just POLA plus offer safety. Offer safety takes care of much risk, leaving some residual risk on the contract misbehavior (e.g., auction deciding top bidder is not the winner). All this we knew.

There's a particular property of the OTC Desk that really surprised me when it was pointed out: The customer has zero residual risk on misbehavior of the OTC contract. The OTC contract composes with the covered call contract in such a way that all of the customer's residual risk is only on misbehavior of the covered call contract. This starts a virtuous cycle: to the extent that the covered call is a highly reused component, we can expect it to be well vetted. To the extent that other contracts delegate their customer's risks to well vetted contracts as components, these well vetted contracts get more highly reused. This opportunity to delegate risk to well vetted contract components enables more contracts to be written at lower risk --- beyond even the lowering of risk provided by offer safety.

[rowgraus]

This is a really important discussion that we need to do more of. I want to be able to talk about our benefits concretely in a way that resonates with people on first hearing. I think offer-safety in general and Chris's related point about composition is easy to explain (though the composition argument requires that they first accept the security argument, so it's a bit more challenging upfront). However, is there something more that can be said based on the initial benefits stated:

1. that the invites are themselves payments that fit within our generic notion of erights. This is normally what we think to highlight.
2. That most of our contracts are generically parameterizable --- that they can exchange any kind of eright without needing knowledge of the specific eright.

As written, these are far too abstract for me to really grasp their significance - and I expect that's true for most listeners. For new audiences, what are some example end-user-level capabilities that we enable through these characteristics? How can we make this more tangible?

[rowgraus]

@erights @Chris-Hibbert just want to ping on this.

As an additional question: does our invite-structure have implications for privacy (or any other clear user-facing benefits) that we can be talking about? It seems to me that it should, but I don't know enough of the details to be sure.

[DavidBruant]

I wrote a bit about that here: #81
I don't think i came around to writing more on the security benefits of invites (or at least, i cannot find what i wrote any longer)

[Chris-Hibbert]

In the same issue David references above, I wrote

The .chainmail files should be talking about guarantees that are relevant to the API, and the calling conventions. promises about deeper behavior should be documented, but arguably, elsewhere.

We don't capture the security properties at all in our TypeScript descriptions. We should figure out whether there's a way to formalize these and write them down somewhere. They are touched on at most glancingly in the API docs we've produced.

[erights]

We should figure out whether there's a way to formalize these and write them down somewhere. They are touched on at most glancingly in the API docs we've produced.

Yes, please! Desperately needed!
https://agoric.com/papers/reasoning-about-risk-and-trust-in-an-open-world/abstract/ formalizes

• the mint maker in a way that should generalize to formalizing ERTP.
• the escrow exchange agent in a way that should generalize to some aspects of Zoe.

However, this paper may be much more formal than what you have in mind.

[erights]

Some of our existing explanations of Higher-order composition:

Paper "Distributed Electronic Rights in JavaScript" starting in Chapter 3

Talk Higher-order Smart Contracts across Chains starting at 21:58

Some concrete motivating uses cases

Paper The Digital Path: Smart Contracts and the Third World

Both "The Digital Path" paper and the "Higher-order Smart Contracts across Chains" talk start with Hernando de Soto's explanation of the informal economy, and how to better understand and address de Soto's "price of informality". The talk explains the price of informality as a reification failure preventing the higher order composition that makes formal economies so rich.

[erights]

Hi @Chris-Hibbert , it seems this is about the same topic you are thinking of writing about, so I assigned to you and @Tyrosine22

[gacogo]

We should figure out whether there's a way to formalize these and write them down somewhere. They are touched on at most glancingly in the API docs we've produced.

Yes, please! Desperately needed! https://agoric.com/papers/reasoning-about-risk-and-trust-in-an-open-world/abstract/ formalizes

• the mint maker in a way that should generalize to formalizing ERTP.
• the escrow exchange agent in a way that should generalize to some aspects of Zoe.

However, this paper may be much more formal than what you have in mind.

The anchored link here is dead - It should resolve to this one: https://papers.agoric.com/papers/reasoning-about-risk-and-trust-in-an-open-world/abstract/