Principles of the Brave Ledger (0.8.40)
The Brave Ledger is a BTC-based micropayments system for users and publishers.
To begin to understand the Ledger, it's helpful to understand a few concepts from the Brave Vault. In particular, a persona is an anonymous identity -- it identifies a set of browsing behaviors without actually knowing who you are.
From the Ledger's perspective,
the most important property of a persona is the value of its
there are two possible values
If the browsing experience is
then third-party advertisements are not displayed by the browser;
third-party advertisements may be replaced by the browser.
Accounting interactions with consumers are:
anonymous: Brave Software should not be able to correlate publisher visits with contributions; and,
accountable: Brave Software should be able to reconcile contributions and publisher visits only on an aggregated basis.
Note that payments to personas and publishers are made to verified BTC wallets, even though the publisher visits of each persona is anonymous. (Each persona's browsing history remains private.)
Who Funds Whom
There are two ways in which "money enters the system":
a persona with a
ad-freemakes a periodic contribution; and,
an advertiser makes a payment commensurate with the aggregate impressions of advertisements served by Brave Software.
There are two ways in which "money leaves the system":
a persona with a
ad-replacementreceives a percentage of the advertiser payments;
a publisher receives a share of the aggregated contributions associated with the viewing habits of personas who visit that publisher's site.
Of course, Brave Software receives a percentage of the payments entering the system.
In order for either a persona or publisher to be paid, they must have a verified wallet. Brave Software oversees the verification process (though it may use third-parties for this purpose). There are different rules for verification for personas and publishers:
- very small amounts are transferred to personas -- so verification (whilst necessary) is lightweight (e.g., verification by "ownership" of an email address and a phone number); in contrast,
- potentially large amounts are transferred to publishers -- so verification is more extensive, depending on the size and frequency of payments, e.g., similar to the verification spectrum seen for DV, OV, and EV certificates.
The client is responsible for reconciling persona behavior with the Ledger. (However, Brave Software's advertising and accounting servers provide the usual checks for click fraud, etc.)
Bravery setting for the client is
ad-free is selected by the user,
depending on the configuration of the client:
the user may select a fixed contribution amount,
or select an amount from a list of choices,
or enter an amount (subject to an upper limit),
or select a "no contribution" option.
Authorized, but Anonymous, Transactions
The Brave Ledger uses Anonize2 in order to process authorized but anonymous transactions. This anonymization process allows the client and Brave Ledger to authoritatively agree on behavior without linking that behavior to personas, browsers, or wallets.
Although "the math" behind Anonize2 is rather complicated, its operational properties are straight-forward:
There are two servers: a "registrar" and a "surveyor"
A client contacts the registrar, downloads its public key.
The client generates its own public and private keys, constructs a request containing a unique identifier and a cryptographic proof based on the registrar's public key and the client's secret key, and sends the request to the registrar.
If the registrar "likes" the request, it sends back an "intermediate result" that allows the client to construct a "master user token", which it can then use when making requests to the surveyor.
Whenever the client sends a request to the surveyor:
The client sends the unique identifier to the surveyor, and the surveyor sends back an "intermediate result".
The client delays an unpredictable amount of time (to avoid timing correlation attacks).
Using its own secret key and the result from the surveyor, the client generates a "one-time unlinkable token" and uses that to sign a request to the surveyor.
When the surveyor examines the request, it is able to determine that the signature was from a user that is authorized by the registrar; however -- and this is the really clever part -- the surveyor is not able to determine which authorized user generated the request. However, the surveyor is able to determine whether the request is a duplicate.
Of course, this is a very simplistic explanation of how Anonize2 works. If you'd like more details, here are two excellent technical papers and a pointer to an open source repository:
An Overview of ANONIZE: A Large-Scale Anonymous Survey System, IEEE Security and Privacy Magazine, 2015.
ANONIZE: A Large-Scale Anonymous Survey System, Oakland Security and Privacy Conference, 2014.
Ad-Free: Statistical Voting
Earlier versions of this document used "fractional" voting for allocating contributions to publishers. For example, if site "X" has twice as many publisher views as site "Y" for a particular contribution, then site "X" should receive twice as much of that contribution as site "Y". This raises a privacy issue in that it groups sites (and relative weights) together allowing for fingerprinting analysis.
This version of the document uses "statistical" voting instead.
The client makes the contribution,
associating with it a unique
viewingId is used to a create a credential with a Viewing registrar,
and is given the identities of one or more Voting registrars that will authorize the
viewingId to cast a ballot.
Each ballot contains a single publisher identity.
As with fractional voting, the client calculates the relative weights of publisher views for each site. Then, for each of the Voting registrars that it is authorized to use, it selects a publisher identity using an unpredictable, but weighted, algorithm. For example, if site "X" has twice as many publisher views as site "Y" for a particular contribution, then site "X" should be twice as likely to be selected for a ballot as site "Y". (statistically) it should be twice as likely to be selected
Ad-Replacement: Peanut-Buttering Process
The total payments from advertisers are aggregated into one sum,
and the total views from the
ad-replacement personas are aggregated into a weighted list for publishers.
From the total payment,
our ad-match partner takes a share (15%),
Brave Software takes a share (15%),
a certain percentage of the total payment is reserved for
ad-replacement personas (15%),
and the remaining amount is allocated to the publishers (e.g., 55%).
The payment to each publisher is then calculated using the weighted-ratio method.
In order to enhance privacy,
the payment to each
ad-replacement persona are calculated independently of the actual impressions served to each persona --
Brave Software does not keep track of which personas are served which impressions.
At the end of each reconciliation period (e.g., every 30 days since client initialization),
the accounting server performs the peanut-butter process in order to determine the amount to fund
both personas with a
Bravery setting of
ad-replacement, and publishers.