Implementation of Blind Off-Chain Lightweight Transactions (BOLT)

[jakinyele]

Motivation and Overview

BOLT is a system for conducting privacy-preserving off-chain payments between pairs of individual parties. BOLT is designed to provide a "Layer 2" payment protocol for privacy-preserving cryptocurrencies such as Zcash, by allowing individuals to establish and use payment channels for rapid/instantaneous payments that do not require an on-chain transaction.

BOLT currently exists as a specification and proof of concept implementation partially in Charm by Ian Miers and Matthew Green (the original authors of the BOLT protocol).

Based on my recent efforts in implementing the BOLT protocol in Rust (work in progress), the goal of this project is to build on the BOLT library (or libbolt) and develop a full node (boltd) that interfaces with Zcash (e.g., a BOLT-compatible cryptocurrency). Both the libbolt library and boltd software are intended to be released as open source to support use cases such as privacy-preserving micropayments.

Therefore, this project will benefit the Zcash ecosystem and further the broader goals of addressing the scalability problems of cryptocurrencies like Zcash and beyond.

Technical Approach

My previous work focuses on the development of the Bolt library (or libbolt) and the core cryptographic components of the BOLT payment channel protocol (e.g., bi-directional payment scheme). To build on this work, I will provide routines for constructing and parsing the messages required for interactive off-chain transactions with (one or more) remote BOLT participant(s), and the full node will provide necessary routines that can interface with the cryptocurrency node (e.g., Zcash) via its interface.

Boltd will include supporting functionality for channel negotiation, channel funding, activation, payment and closure. This may also include a separate component to monitor the blockchain to manage dispute resolutions between participants.

The boltd node will be connected to the currency P2P network, and will support commands via an RPC interface. I will leverage existing code developed in Go by the Lightning Network project (e.g., lightningd).

Background and Qualifications

The team consists primarily of J. Ayo Akinyele (Johns Hopkins University and YeleTech Security)

In terms of qualifications, a majority of my work is cryptographic engineering related and I've contributed to a number of open source projects as a result. In particular, I am the main developer behind the following open source projects:

• Charm-Crypto: a rapid prototyping framework for advanced cryptosystems. Written in Python/C and used extensively by academic researchers and practitioners around the world. See https://github.com/jhuisi/charm.

• OpenABE: a new commercial-grade open source attribute-based encryption library. Written in C/C++ and publicly available at https://github.com/zeutro/openabe.

• Libbolt: work-in-progress implementation of the BOLT payment channel protocol in Rust. Will be released as open source in the near future on GitHub (via Zcash Foundation).

Evaluation Plan

I anticipate the following milestones that mirror the technical approach:

1. Explore optimizations for the range proofs in the Pay protocol (default approach is inefficient).
2. Explore mechanisms to safely and securely link Rust into Golang code (for the purposes of integration with boltd).
3. Implement the dedicated daemon (boltd) in Go that implements BOLT communications with remote parties. This daemon uses HTTPS/JSON communications, incorporates libbolt and interfaces directly with the cryptocurrency node.

Security Considerations

The security implications of this project is to mitigate the bottleneck of on-chain transactions on the Zcash network. With off-chain transactions, the BOLT protocol dramatically reduces the transaction volume arriving at the Zcash blockchain without adding new trusted centralized entities.

See the attached full proposal.

boltd_full_proposal_Q2.pdf

[mineZcash]

Bolt is a very exciting concept, I remember reading about it on the Zcash blog: https://blog.z.cash/bolt-private-payment-channels/

Is this a progression of Ian's previous work, or a different implementation? Has Ian agreed to assist you if this project is funded?

[jakinyele]

@mineZcash Yes, it is definitely a progression of Ian's work. The authors (Ian and Matt) have agreed to lend their expertise in terms of the design and implementation as well.

[b-g-goodell]

Do you know of any technical/theoretical considerations that will present hurdles to this project? If so, can you elaborate on some of the details of those problems?

Example: off-chain approaches often use non-interactive refund addresses that don't require trusting the refunder or any third parties (BOLT uses refund tokens)... but glimpsing through zcash documentation suggests to me that refunds aren't baked into ZCash this way.

[jakinyele]

Not that I can think of. However, can you clarify what you mean by "non-interactive refund addresses" in your example? So far, my understanding is that there will need to be additional opcodes added to the Zcash scripting language (similar to Bitcoin) to make this work. This will require help/assistance from the Zcash company but that is outside the scope of the proposal. If there are any technical hurdles that you think I'm missing that should be addressed, please let me know. Thanks @b-g-goodell!

[tromer]

What are your thoughts on use cases and specific applications that will use your boltd daemon? Are there applications that can be built/integrated concurrently with the daemon development, to exercise and demonstrate its capabilities, performance, and RPC design?

[jakinyele]

@tromer Thanks for your questions!

Some of the best use cases are micropayments (small to medium-sized) and third-party payments. To demonstrate the utility of the bolt daemon, I could compile the client into JavaScript (via WebASM) and link into a Browser plugin. One concrete use case for this web application would be privacy-preserving micropayments to users favorite content publishers (similar to Brave).

Alternatively, in the shorter term, I could deploy a test network similar to Lightning that enables test transactions via command line utilities. The latter will be necessary for testing and performance measurements during boltd development.

[tromer]

The Zcash Foundation Grant Review committee has reviewed your pre-proposal, including the above discussion, to evaluate its potential and competitiveness relative to other proposals. Every pre-proposal was evaluated by at least 3 (and typically more than 4) committee members .

The committee's opinion is that your pre-proposal is a promising candidate funding in this round, and the committee therefore invites you to submit a full proposal.
Please submit a full proposal by June 15th, following the detailed structure described in the Call for Proposals. We encourage you to submit a draft as early as possible, to allow for community feedback.

[daira]

wrote:

So far, my understanding is that there will need to be additional opcodes added to the Zcash scripting language (similar to Bitcoin) to make this work. This will require help/assistance from the Zcash company but that is outside the scope of the proposal.

Zcash doesn't implement shielded features in terms of script op-codes (unlike Zerocash for which BOLT was originally proposed). So some nontrivial specification work is required here, which needs to be coordinated with other feature plans. Also bear in mind that it is likely to require a network upgrade, and the lead time from feature specification to activation of an upgrade is at least 6 months. (We might be able to reduce that given more experience with network upgrades, but not by much.) So it would be helpful to front-load work on the specification of any necessary Zcash changes — which I and probably other Zcash company engineers would be happy to help you, Ian and Matt with if this proposal is accepted. I suggest that your side of this specification work should be included in the proposal.

[jakinyele]

Hi @tromer. My apologies if my full proposal for bolt work was not easy to find above. I'm adding it again here for inclusion in the grant committee review. Thanks again for the consideration.

boltd_full_proposal_Q2.pdf

[mineZcash]

J. Akinyeles Zcon0 talk about BOLT: https://youtu.be/z2l5NqJ6sOI

[sonyamann]

I'm thrilled to inform you that the Grant Review Committee and the Zcash Foundation Board of Directors have approved your proposal, pending a final compliance review. Congratulations, and thank you for the excellent submission!

Next steps: Please email josh@z.cash.foundation from an email address that will be a suitable point of contact going forward. We plan to proceed with disbursements following a final confirmation that your grant is within the strictures of our 501(c)(3) status, and that our payment to you will comply with the relevant United States regulations.

We also wish to remind you of the requirement for monthly progress updates to the Foundation’s general mailing list, as noted in the call for proposals.

Before the end of this week, the Zcash Foundation plans to publish a blog post announcing grant winners to the public at large, including a lightly edited version of the Grant Review Committee’s comments on your project. The verbatim original text of the comments can be found below.

Congratulations again!

Grant Review Committee comments:

The proposal, by cryptographic engineer J. Ayo Akinyele, is to implement the BOLT (Blind Off-Chain Lightweight Transactions), a ”Layer 2" payment protocol for privacy-preserving cryptocurrencies such as Zcash, allowing individuals to establish and use payment channels for instant payments that do not require an on-chain transaction. This is a promising approach to achieving scalability, analogously to the Lightning network on Bitcoin but in a privacy-preserving way.

The committee recognises the proposer’s clearly stated approach, strong background and ability to deliver this important project, which will be beneficial for Zcash, as well as other cryptocurrencies.

Funding of the full amount is recommended.