Re: FYI: Lightning will work across ledgers

Great summary! Thanks Evan

On 22 February 2017 at 09:47, Evan Schwartz <evan@ripple.com> wrote:

> It made me realize that inter-blockchain Lightning would end up quite
> functionally equivalent to ILP + crypto conditions.
>
>
> I very much agree with this point from Ryan, and Jehan's and Tony's points
> about simplicity being key.
>
> If you frame the issue of interoperability between blockchains/ledgers in
> a certain way, the way I see it is that you'll come to something like 6
> major decisions. And if you pick a certain option at each of those major
> forks in the road, you'll effectively end up at Interledger.
>
> The first split is probably the biggest, and that's whether you build
> internetworking into blockchains/ledgers or build a separate component to
> handle internetworking. In approaches like Cosmos
> <https://cosmos.network/whitepaper> / Polkadot <http://polkadot.io/>,
> blockchains must be specifically designed to be part of those systems and
> must be aware of or subservient to one or more other blockchains. This
> could allow a deeper type of integration, but comes with a complexity
> tradeoff. With Lightning / Interledger, internetworking is handled by a
> separate component (Lightning nodes or Interledger Connectors). This is
> simpler and can incorporate a wider variety of ledgers, but is primarily
> useful for trading assets of value across ledgers. Interledger also uses an
> abstraction over the functionality expected from the ledger layer (instead
> of building simpler ledgers to imitate blockchains) and tries to minimize
> the functionality required from the ledger layer.
>
> If you are going the route of having separate internetworking systems, the
> key building block you need is the Lightning / Interledger / Cross-Chain
> Atomic Transaction flow. This flow ensures that senders cannot lose money
> in multi-hop transactions, no matter who the intermediaries are. Shifting
> the risk from senders and recipients to the intermediaries is what enables
> us to even start conversations about routing and all of the other issues
> below. The fact that many projects have settled on the same transaction
> flow seems to suggest that it's just this idea's time.
>
> Given the idea of connectors and the transaction flow, some of the other
> major decision points are as follows. Those in bold are the choices that
> currently make up the Interledger approach.
>
>    1. Crypto Algorithm(s) for Conditional Transfers
>       - Crypto Conditions - flexible, combinable, upgradeable, but
>       relatively complicated. Spec here
>       <https://tools.ietf.org/html/draft-thomas-crypto-conditions-02>
>       - *SHA-256* - lowest common denominator. Arguably, you can only
>       make payments across ledgers that support the same condition type anyway so
>       you might as well standardize on this. See discussion here
>       <https://github.com/interledger/rfcs/issues/153>
>       - Something else - Stefan had a good way of describing the options
>       here <https://github.com/raiden-network/raiden/issues/399>
>    2. Ledger-Agnostic Addresses
>       - Centralized Authority - something like IANA for the Internet
>       - Decentralized Authority - blockchain or DHT
>       - *No Authority* - using conditional transfers you know
>       definitively if payments are routed to the correct place, so address
>       collisions are arguably less of a problem. See spec here
>       <https://github.com/interledger/rfcs/pull/154>
>    3. Packet Format
>       - Binary (Protobuf, CBOR, ASN.1/OER, custom) - more efficient, less
>       developer-friendly. Some of these options are more widely supported
>       (Protobuf) and some are simple enough that they could be implemented from
>       scratch (OER)
>       - Text (JSON, XML, custom) - human-readable and easier for
>       development but less efficient and slower
>       - *ASN.1/OER + JSON* - use a simple binary format that is fast to
>       encode/decode and to write a parser for, and then also define a JSON
>       version for development and JSON-based ledger protocols. See discussion
>        here <https://github.com/interledger/rfcs/issues/146>
>       4. Routing Protocol (thanks to Michael Warnock for these points)
>       - Link-state - every router must know about all of the others, so
>       this doesn't scale to larger networks
>       - Distance-vector - uses the cost of routes to make routing
>       decisions, close to what we have implemented in the ilp-connector
>       <https://github.com/interledgerjs/ilp-connector> now
>       - *Path-vector* - has more information available for preventing the
>       pathological cases that come up in IP routing, and is used in BGP, which
>       has the most analogous use case to ours
>       - Hybrid - something like what Bitfury suggests in their whitepaper
>       <http://bitfury.com/content/5-white-papers-research/whitepaper_flare_an_approach_to_routing_in_lightning_network_7_7_2016.pdf>
>    5. Layering vs Bundling
>    - Built-in Privacy - Lightning has onion routing built in to the core
>       protocol
>       - Built-in Identity - traditional payment protocols include
>       information about who is sending money and why
>       - *Bare Minimum interledger Protocol* - core protocol only includes
>       the information necessary to make routing decisions. Other functions, like
>       privacy and identity, are handled by layers above and below the interledger
>       layer
>    6. Prefunded vs Postfunded Channels
>       - Prefunded - as far as I know, Lightning requires all channels to
>       be prefunded. This means there is less risk but it's also more expensive to
>       tie up capital for this purpose
>       - Postfunded - credit or "trustlines" are cheaper because they do
>       not require capital but they do come with counterparty risk. May be more
>       appropriate in circumstances where the participants have a closer
>       relationship
>       - *Both *- Interledger abstracts away the difference between bond-
>       and credit-based bilateral relationships, letting users and connectors
>       choose which one makes the most sense for their use case, trust model, and
>       level of risk tolerance
>
> A couple more decisions that one could argue should be part of this set
> are what number format to use for expressing interledger amounts, whether
> quotes are locked or not, whether routers are stateless, etc.
>
>
> On Wed, Feb 22, 2017 at 4:59 AM Tony Arcieri <tony@chain.com> wrote:
>
> On Tue, Feb 21, 2017 at 3:09 PM, Jehan Tremback <jehan.tremback@gmail.com>
> wrote:
>
> All channel implementations are dealing with a similar concept, and just
> do it in different ways to work on different platforms and have different
> capabilities. One of the main things that sets Lightning apart is that the
> code is very complex, to accommodate the limitations of Bitcoin script.
> Sure, you *could* use various layers and adapters to make it work, but
> would you want to? I'm guessing most people will want to use something that
> is tailored to their use-case and easy to build upon.
>
>
> Yes, +1 this. While it's great that Lightning can work across ledgers, the
> one problem you claim as unsolved (exchange rates) is already solved by
> Interledger, and Interledger provides a substantially simpler and much more
> general, *layered* implementation strategy.
>
> I really wish the Lightning Network folks would consider isolating and
> compartmentalizing some of their ideas into a more general system, and have
> talked with a few of them in person about this, but until they do to me at
> least it really doesn't seem more interesting than Interledger, just a lot
> more highly-coupled and intrinsically complicated.
>
> --
>
> Evan Schwartz
> Software Engineer
> Managing Director of Ripple Luxembourg
>