The Boston Fed has been monitoring the evolution of digital currencies and blockchain technologies for years, but it wasn’t until late 2015 that we decided to deepen our working knowledge through experimentation. It was around this time that senior Federal Reserve officials were beginning to publicly speak about the need to study blockchain’s potential applications. In June 2016, former Federal Reserve Board Chair Janet Yellen encouraged central banks from all over the world to learn about Bitcoin, blockchain, and distributed ledger technologies.¹ That October, Federal Reserve Governor Lael Brainard addressed the International Institute of Finance and affirmed the Fed’s interest in understanding the developments, opportunities, and risks associated with innovations like blockchain.²

Also in 2016, the research firm Gartner placed blockchain near the peak of “inflated expectations” on its Hype Cycle graphic, which predicts when certain technologies will be adopted by the mainstream.³ At that time, some analysts thought the technology was five to 10 years from widespread use. At the Boston Fed, we wanted to cut through the noise and share what we learned with others. From the start, we had this quote from the playwright George Bernard Shaw in mind: “The one lesson that comes out of all our theorizing and experimenting is that there is only one really scientific progressive method; and that is the method of trial and error.”

Choosing Ethereum

From the early days of Bitcoin, our team had been watching developments in blockchain, but it wasn’t until the Ethereum platform—which expanded on the concept of smart contracts—was introduced that we started devising a proof of concept. Ethereum co-founder Vitalik Buterin described the platform as “a blockchain with built-in Turing-complete programming language, allowing anyone to write smart contracts and decentralized applications.”⁴ Ethereum was managed through a community of open source developers, and it appeared to have good documentation and support from existing developers when we decided to use it for our early experiments. From the start, the team had some clear goals and milestones in mind, including:

• learn about the technology
• demonstrate viability
• test design features critical to central bank services
• validate a lean development effort with minimal investment

Priming the Pump

Before work could begin on a blockchain proof of concept, the team needed to prime the proverbial pump by procuring the basics. That included downloading and running Ethereum, as well as interacting with Ethereum via its software, Geth’s Command Line Interface (CLI), and exposing Geth’s JSON-RPC interface. These tools allowed a simple transaction to be executed.

While the setup—a relatively straightforward command-line console interface—wasn’t difficult by technologist standards, our team soon recognized the platform was not simple enough for mainstream use. It would be one of many learnings to come.

The Use Case

Once the API was established and the team had a working knowledge of how inputs and outputs were created in the protocol, defining a specific use case became the next priority. An opportunity presented itself almost immediately.

The Boston Fed manages the development and operation of the Federal Reserve’s accounting platform, which processes an average of 250,000 transactions per day. These transactions represent account-level settlement entries for items cleared by the Fed’s retail payment applications (e.g., ACH, check, cash), and summary flows from the Fed’s wholesale payment applications (e.g., Fedwire Funds and Securities), which are separately settled by a real-time account balance system. That gives us intimate knowledge of how the system performs key tasks such as balance sheet management, account reconciliation, and tracking high-volume, high-dollar financial transactions between banks.

We soon realized one relatively simple but important operation—reconciliation of adjustments between depository institutions and general ledger accounts—could be achieved, and possibly improved, using smart contract execution on a blockchain.
The process requires a ledger that records the value of the different transfers between parties that are enabled by the Fed’s payment systems, reconciles external and internal applications, and has strong resiliency and security requirements.

Our proof of concept sought to test functionality, including the ability to:

• load the balances of depository institutions onto the Ethereum ledger (Mock data was used for depository institution identifiers and balances.)
• establish wallets to represent a small number of pseudo depository institutions
• mimic depository institutions transferring balances among themselves
• validate transactions, verify balances, and reach consensus among the nodes
• create corresponding general ledger entries via smart contracts to reflect those transfers

We gained two key advantages by choosing to constrain the use case to a subset of tasks within a larger, well-known system: 1) simplicity; 2) the ready availability of knowledgeable business, technical, and cybersecurity resources. It is important to note that the purpose of our experiments was to learn the technology. We had no explicit plans to implement the technology in our production systems.

The Development Process

Like many organizations beginning to experiment with blockchain, we had to acquire knowledge of the programming language and tools. Since the Boston Fed viewed the project as a learning opportunity for our internal technologists, we decided not to work with any external firms so we could maximize our hands-on learning.

“In addition to making sure that the development tools were safe to use, it was important for us to document the scope and assumptions surrounding the work so that everyone remained on the same page.

Naturally, the Boston Fed takes the security of its data and system seriously. To avoid confusion, we were very clear to say that our proof of concept did not interact with any of the Fed’s payment applications or use any real-world data. This changed the risk posture dramatically and gave the development teams more freedom to experiment.

As the team iterated over new tools, frameworks, hosting environments, etc., we would regularly document our common understanding, including testing goals, products we were using, known risks, mitigating factors, assumptions, and terms of use.

This had an added benefit of making sure that our testing was focused and aligned with management expectations.”

—Matthew McHugh, Director of Information Security Risk & Compliance, Federal Reserve Bank of Boston

Additionally, we worked in close partnership with our cybersecurity team, because many of the tools needed to develop the application were new and/or open source. The team worked with us to detail designs, assess risks, evaluate tools, and verify processes. With every iteration, we were guided first by a commitment to security, while remaining open to new ways the technology could help us meet our objectives. The Bank also had to make sure our internal laboratory environment applied the same control objectives required by existing systems. If, for example, we demonstrated viability, but without the expected controls in a production environment, the value of the project could be negatively impacted.

The Tech Stack: Ethereum

With everyone from leadership to IT on board, the tech stack took shape. In addition to the Ethereum platform described above, the stack running on Ubuntu in Amazon Web Services (AWS) included:

• Ethereum, Geth, JSON-RPC
• Tomcat, Angular 1, Java, Spring MVC
• supplemental database (for reporting and journaling purposes)

Ethereum Results

The success of any experiment depends not only on how well the solution works, but also what’s learned along the way. This first trial provided many learning opportunities.

The team used the existing framework and methods provided through Ethereum’s Geth JSON-RPC API, and a series of JavaServer Pages (JSP) to interact with the Ethereum back end. These pages enabled the submission of a transaction and pages for searching transactions on different criteria. Transactions and queries could all be performed as expected from a user-interface perspective. The user interface, the front end, would remain the same through the next phase of the project. We were interested in the portability of the code. Our implementation of the back-end Ethereum platform, however, offered many insights, though it ultimately would not prove viable for our use case for several reasons.

First, at the time Ethereum offered limited ability to query by a range. For example, if we sought results from transactions between $200 and $400, a query would return all transactions. Picking a subset of those transactions required a supplemental database external to the Ethereum back end.

Second, though the appeal of Ethereum as the platform of choice was based on many factors, one of them—the availability of support and documentation—proved more challenging than expected. Though it has a large developer community, there weren’t many members equipped to answer questions about functionality beyond the basics.

Third, ensuring consensus among participating nodes still required a proof-of-work protocol. Even within a confined environment, the time necessary to create a block was slower than could be tolerated in a production environment. Viability in this case could not be demonstrated.

Another core element of the Ethereum protocol involved a concept known as “gas,” which, as the name implies, is the fuel—in the form of cryptocurrency—of the platform. Gas is required as smart contracts execute transactions and the “miners” in the network create the blocks enshrining the changed state. Gas is used to pay the miners for the work they do, but it’s also a security feature. If gas is required for each executed transaction, then an attacker seeking to cause disruption to the network by spamming it with endless transactions would also need to pay for each fraudulent transaction. This feature means a supply of “ether”—the account-based cryptocurrency native to Ethereum that represents the “gas”—needs to be maintained to facilitate transaction execution. Our use case focused on accurate transfers to perform account reconciliations—adding gas to each transaction was impractical and unnecessary, given that the “miners” were not decentralized, untrusted participants, but rather nodes within a closed network.

Finally, when functionality is not native to the platform, challenges abound. A core value proposition of Ethereum was the ability to build smart contracts and applications beyond digital currency. However, it was built as a permissionless and public network. That meant running a cloned instance of the platform within an internal, and therefore “private,” laboratory environment—and native Ethereum at that time did not provide membership services. So, onboarding users and restricting access to the platform and read/write functions proved incompatible with the design of the Ethereum platform of 2016. But since a membership service is a critical feature of our accounting system, the inability to enable these controls ultimately made Ethereum ill-suited as a platform for this use case.

Though Ethereum couldn’t support the project goals, the first trial successfully demonstrated the strengths and weaknesses of the platform at that time. The team learned much about basic performance, stability, encryption, reporting, diagnostic tools, and compliance options for meeting security requirements. These lessons would serve us well in the next trial.

The views expressed in this report are those of the authors and do not necessarily represent positions of the Federal Reserve Bank of Boston or the Federal Reserve System.