If you are just starting to learn about payment channels, I highly recommend reading Sparky: A Lightning Network in Two Pages of Solidity.

Explain Universal Composition Like I Am A C Programmer

There are three jargons to explain:

Ideal functionality

Protocol

Composition

Let me butcher these ideas by explaining them in a way that’s hopefully easier for programmers to understand.

An ideal functionality (notated as 𝓕) is like a header file. It specifies the API and the security properties a protocol should have.

A protocol (notated as π) is like the implementation file of a header. In UC jargon, the protocol emulates the ideal functionality. By “emulate”, it means that the protocol is “indistinguishable” from the ideal functionality. In other words, the tests suite passes.

The Universal Composition Theorem essentially says that when designing a protocol, you can use ideal functionality 𝓕 as a subroutine, and later replace it with an actual protocol π satisfies 𝓕.

This is nice, and rather amazing.

You can decompose a complex distributed system into smaller protocols. And if you can prove that each of the components satisfies the security properties specified in their “ideal functionalities” (aka header files), the system as whole is guaranteed to be as secure as its parts.

State Channel in UC Framework

The “ideal functionality” (aka header file) for state channel is like this:

This is a description of what the protocol should do, and some of its security properties.

The fancy looking 𝓐 is the adversary. In the functionality we specify that the all messages are known to the adversary. In other words, messages are published to a public ledger.

aux_input / aux_output are just methods that allows the functionality to read from and write to the blockchain.

Big-O notation that specifies the protocol’s performance bound. O(1) is the time required for off-chain collaboration if everyone is honest. O(Δ) is the time required for on-chain dispute resolution.

More in the paper.

The “ideal functionality” just describe what the protocol should do, and how well. We also need an actual protocol that emulates (aka “implements”) the ideal functionality.

The protocol is a smart contract written in pseudocode:

If you have written Solidity before, you should be able to understand it if you stare at it for long enough. (Read the paper!)

*Bang* Duplex Payment Channel

The reason that the Universal Composition Framework is a big deal (2300+ cites) is that you can write proofs about distributed systems similar to how you can write programs.

Suppose that the generalized state channel modelled above is correct (proven in the appendix), then we can use it to build a payment channel protocol.

The UC framework guarantees that the final program is also correct. Interactions between the parts and the whole would not break security.

To construct duplex payment channels, we first specify an ideal functionality that describes the API and security properties it should have:

We can see the time performance in Big-O, as well as what information is made public to the adversary.

Then the actual protocol definition:

What’s cool here is that the duplex channel protocol can take advantage of the ideal state channel. This is a hybrid protocol that combines some ideal parts, and some concrete parts.

The Universal Composition Theorem says that this is ok! As long as the hybrid protocol can be proven to emulate its ideal functionality, the Theorem allows us to substitute the actual state channel for the ideal state channel ℱstate.

Conclusion

This paper (so far) is more readable, and more general, than the original Lightning Network paper. Read it!

I’ve formed a Telegram CryptoReaders Group. We help each others read papers on cryptography or distributed system. Every two weeks we plan to do an online remote MeetUp to discuss the paper we’ve read.