Introducing Pippin — High Performance, Production-ready External Wallet for Nano and Banano

13 Dec, 2019 • 4 min read

Pippin is a High Performance, Production-Ready Developer Wallet for Nano and BANANO

Imagine that you wanted to integrate Nano — the fee-less, instant, and environmentally friendly cryptocurrency, or BANANO — the fee-less, instant, rich in potassium cryptocurrency into your application. Whether it’s an exchange, casino, faucet, game, store, or vending machine— one of the first things you’ll need to do is figure out how to interface with a wallet.

Intimidating right? Luckily if you peruse the Nano Documentation you’ll quickly find out that Nano has a developer wallet built-in, right into the node! It has a full set of APIs that lets you create accounts, send Nano, receive Nano, etc.

But then when you read a little more about it and see that the developer wallet isn’t recommended for production integrations, it’s tightly coupled to a node, and what if you have disk space or bandwidth constraints? Running a full node probably isn’t something that you want to do. The answer to these problems is external key management . But what does that mean? Well, it basically means writing your own wallet, manually crafting and signing blocks, and using any node(s) to publish the block. All while taking proper precautions along the way to make sure blocks are confirmed and avoiding duplicate transactions. Today we’re announcing a new developer wallet that gives you external key management and incredibly high performance right out if the box…

What is “Pippin” Anyway?

To put it simply, Pippin is a Nano (and BANANO) wallet for developers. Pippin is the first wallet of its kind that is 100% compatible with the developer wallet (aka “node wallet”) APIs. Of course the node wallet isn’t recommended for a lot of use cases, but a lot of developers use it anyway — because as you might expect, it’s the easiest solution and it generally works well enough. One of the goals of Pippin is to provide a production-ready, external key management solution that’s incredibly easy to setup and maintain.

Pippin has numerous advantages:

It’s a drop-in replacement for the node/developer wallet
It has native support for DPoW and BPoW
It’s completely detached from the node — meaning, you can use Pippin with any public node (no need to run your own node, you could also run a node in 1 location and have pippin on any number of machines using the same node)
It’s compatible with multiple database backends (SQLite, MySQL, PostgreSQL)
It can lazily auto-receive transactions (for example if you don’t want to compute PoW every time your account receives some coins but you also don’t want to explicitly receive them, Pippin can just receive blocks on demand when you need to perform a send — this also works well for when your wallet is locked and cannot auto-receive)
It supports encrypting seeds and private keys
Is fully asynchronous and easily scalable thanks to per-account, thread-safe distributed locks.

It’s Also Very, Very Fast

A benchmark was constructed that:

Created a new wallet with 21 accounts, and opened one of the accounts with some coins. (1 block)
Create 20 transactions to 20 different accounts from the first account. (20 blocks)
Receive all 20 transactions across the 20 different accounts (20 blocks)
Send all of the coins back to the original account in 20 more transactions (20 blocks)
Return coins to sender (1 block)

The same node was used for both Pippin and the node wallet, the same PoW provider was used, and the exact same amount of transactions were made in the exact same way.

This was repeated 3 times for each wallet, under the same conditions. Pippin was consistently at least twice as fast as the node wallet.

The same node was used for every run with both Pippin and the node wallet, the same PoW provider was used, and the exact same amount of transactions were made in the exact same way.

The Technology Behind Pippin

Pippin is written in Python, it is able to perform incredibly fast by using libraries such as asyncio, uvloop, asyncpg/aiosqlite/aiomysql, rapidjson, and others.

It uses the brilliant nanopy library for signing blocks and generating work, which itself uses C-bindings for ed25519 and blake2b (in the most basic terms, this means that it’s fast).

…but how is it so fast? Pippin uses a brilliant per-account distributed locking mechanism that’s backed by Redis. This means that every account can operate completely independent of one another, while still operating in a synchronous fashion on its own chain. So if you push 500 transactions that belong to account #1, then push a transaction that belongs to account #2 — the account #2 transaction will get processed immediately, even though account #1 has 500 pending requests to handle. This mechanism allows for extremely high concurrency and scalability as you increase the number of accounts, it even is safe across multiple processes.

Additionally, pippin uses a process pool that’s configurable for local work generation, although GPU PoW isn’t natively supported, you can use external work peers, run your own nano-work-server instance, or use a service like BoomPoW.