Those following Github are aware of the significant progress we’ve made on BAT Mercury (the first phase of work outlined in our roadmap) since our last blog post. The first BAT-enabled version of the Brave browser will be the 0.19 release. As such, we want to provide an overview of the backend and client library changes already completed and deployed in preparation for the imminent BAT Mercury launch.
We also want to address the time table for landing in 0.19 and the first phase of BAT Mercury. The backend and client libraries are on target. If we rushed to meet our previously announced deployment date, the product would not have met the high standards our users deserve. There are a number of open issues in the browser ledger code that we noted during BAT Mercury integration work. None of these are breaking, but together they fall short of our minimum viable product standards. More involved browser-side refactoring is needed for launch. We appreciate the patience of everyone involved as we want to offer the best to our users and community.
Given our rate of progress on the more comprehensive browser-side refactoring, we’re happy to announce that the first phase of BAT Mercury will be live by Friday, October 6th. You can follow our run up to the release of 0.19 here.
BAT Mercury Components
Note: All of our BAT software is developed as open source software on our github account.
The BAT-ledger repository
The BAT ledger repository is the primary service of the platform. The client library in the browser talks to the repository. The “ledger” server is responsible for several things:
- Browser wallet creation: According to the Practicals document, wallet creation is a two-step process. First, the client (browser) creates a keypair using the excellent NaCl library. The secret key is held by the client and not kept anywhere else. Next, the browser uses the secret key to sign a data packet for the wallet provider. The packet proves that the client “knows” the secret key in the keypair. The data packet is sent to the ledger server and then to the wallet provider — an important part of the architecture is that the ledger server acts as an untrusted intermediary between the client (browser) and the wallet provider. This allows the ledger server to verify BAT Mercury’s “business logic”, but does not allow the server to initiate transactions. Once verification is complete, the wallet provider generates a BAT wallet.
- Contribution submission: According to the Practicals document, contribution submission is also a two-step process. First, the client (browser) indicates the amount of the contribution in BAT and the ledger server returns an unsigned transaction, which the client then signs with the secret key. This proves that it “knows” the secret key that was used to create the browser wallet. Again, the ledger server acts as an untrusted intermediary between the client (browser) and the wallet provider, ensuring that the client didn’t change any parameters in the data packet. Next, the wallet provider signals success and the ledger server gives the browser a number of anonymous, independent ballot envelopes, based on the size of the transaction.
- Configuration updates: The ledger acts as repository for information used by the client library to provide a better user experience. It contains the list of publicly-known verified publishers, and two sets of rules: one that converts a URL and optionally, a DOM tree, into a publisher-identifier; and a second, that indicates whether a publisher-identifier is eligible for “auto-inclusion.” (As the name implies, “auto-inclusion” allows the browser to decide whether a site should be considered eligible for inclusion in a user’s list of favorite sites. Some sites, such as e-commerce sites, aren’t eligible for auto-inclusion).
Those following closely are aware that we use Uphold.com as a wallet provider. They enable the key feature of associating different deposit addresses with the browser wallet. Thus, each browser wallet has an Ethereum address as well as a Bitcoin address. These deposit addresses are available to the client (browser), so it’s very easy to transition the browser wallet from BTC to BAT: the browser contacts the ledger server for the Bitcoin proof-of-concept and signs a Bitcoin transaction to move the balance to a Bitcoin address that automatically converts the BTC to BAT and deposits it to the browser’s wallet.
The BAT-ledger repository (part deux)
The BAT repository includes a second server, the “eyeshade” server. This is the backend accounting server for BAT Mercury.
The most significant work required for the eyeshade server is to convert all of its units from satoshis to wei. The satoshi is the smallest unit of Bitcoin and the wei is the smallest integral unit of BAT. It takes 10^8 satoshis to make one BTC (100,000,000) but 10^18 wei to make one BAT. Because we want to avoid dealing with fractional numbers, everything in the server has to be denominated in the smallest integral unit. The problem is that numbers like 23089569056300000000 (a little over 23 BAT) can not be represented without a loss of precision. The solution is to use a BigNum package that does arbitrary-precision arithmetic.
In order to future-proof the eyeshade server, units are now represented as two fields: an altcurrency field, which is a string like “BAT” indicating what kind of currency or utility token is in use, and a probi field. The term probi is the plural of probus. It is named after the Roman philologist and cryptographer Marcus Valerius Probus. Unlike the term satoshi, which always refers to Bitcoin, and wei, which always refers to Ethereum and (existing) ERC-20 tokens, the term probi is meaningful only when paired with an altcurrency. Think of it like a vector: you need both a magnitude and a direction to make sense of it.
The BAT-balance repository
BAT balance is a small helper library used by the browser for getting the balance of a browser-held BAT wallet. It polls a BAT balance server to determine the current amount.
Having a separate server may seem counterintuitive to those more versed in cryptocurrencies. The simplest solution would seem to be polling for the Ethereum address balance on one of many public blockchain APIs, including our own. This would be analogous to the strategy used in the Bitcoin proof-of-concept. Here, however, this strategy is not available to us as browser-held BAT are not kept long term under the Ethereum address made available for deposits.
Instead, transfers made to any of the cryptocurrency deposit addresses are automatically transferred in their entirety by Uphold to their internal pool address. This enables the feature mentioned above whereby a user can transfer Bitcoin to the browser BAT wallet and it will be automatically converted into BAT. Furthermore, movements between Uphold wallets are not on-chain and thus incur no additional transaction costs. Contributions in BAT Mercury can flow from browser users to publishers entirely within the Uphold system without being double charged.
The BAT-client repository
The BAT client repository talks to the ledger server and is loaded by the Brave browser. One of the more challenging aspects of implementing the library is supporting the Anonize2 protocol in a browser. Some of the operations in that protocol are computationally-expensive (i.e., noticeably slow), and have to be done asynchronously. Implementing them in a platform-neutral way requires both emscripten (because some cryptography and math libraries are just “wrong” on some platforms) and a threading system independent of the node.js library.
There is also a BAT publisher repository that is used by the client (browser) to maintain a browsing synopsis, such as domains visited and Basic Attention Metric measurements. In a future blog post, we’ll discuss this repository along with the publisher-identification rules to explain how we plan to support publishers and content producers who use YouTube and Twitch.tv.
What You Can Do to Prepare
If you are a current user of the Brave browser and the Bitcoin proof-of-concept system, then you don’t need to do anything other than upgrade to Brave 0.19 when prompted. A new Brave wallet will automatically be created for you. Additionally, if there’s a balance in your existing Brave wallet, then your browser will automagically transfer the balance to the equivalent amount of BAT in your new Brave wallet.
If you are a publisher, or planning to verify as a publisher with Brave, you can sign up at Uphold now and start the process of becoming a verified Uphold member. You’ll need to have a verified Uphold account in order to receive contributions, so there’s no harm in taking care of that “before the rush.”
Brave-verified publishers that have completed the tax-related and KYC-related (know your customer) paperwork for the Bitcoin proof-of-concept will be required to create an Uphold account and go through their verification process to start collecting BAT. However, Brave-verified publishers will not need to re-verify control of their websites.
When BAT Mercury launches, the BAT website will have the terms and conditions posted for review.
Although the Bitcoin proof-of-concept is closing down soon after BAT Mercury launches, no sunset date is set. This will be done by disabling additional contributions in the Bitcoin proof-of-concept and distributing final contributions to existing publishers.
Finally
It is important to remember that use of BAT is not limited to the Brave browser — any developer is allowed to integrate the browser of their choice with the BAT Mercury service (Of course, the developer will need to be able to modify their browser’s source code). In fact, the BAT client library doesn’t have to be used. All of the protocol interactions are defined in the Practicals document. As the roadmap stated, we intend to form a trade group to govern rules and auditing requirements for clients, once BAT in Brave is solid.