eBooks In The Blockchain
Abstract
I will propose a specific way to combine a smart contract in a blockchain network and a file sharing network in such a way, that an open, transparent and “trustless” market for eBooks will become possible. The digital signatures that come with the blockchain network will be used to sign requests in the file-sharing network. Thus encrypted copies of the eBook can be transferred from a caller to a receiver, whenever an appropriate blockchain transaction involving those business partners exists for validation.
Prerequisites
The blockchain
We define a smart contract as a small computer program running in a peer-to-peer network. Our specific smart contract will manage the ownership rights of an eBook by receiving transactions in a chain of blocks in the network. Such chains are commonly called blockchains. For simplicity and whenever it does not lead to confusion, we also use the word blockchain when we refer to the peer-to-peer network maintaining the blockchain data, not the data blocks themselves.
A blockchain can guaranty the validity and integrity of transactions by using a consensus algorithm inherent to its P2P network protocol. This is independent of any central authority or institution.
The file sharing network
As the blockchain is not sufficient to transfer eBook data, a second network is needed.
We propose a file sharing network, though this is very close to what is used today for illegal and uncontrolled file sharing. In contrast to existing file sharing, we are targeting a controlled and secured file sharing network, where each data transfer corresponds to a transaction in the blockchain and its monetary value.
This would mean, that ownership rights and intellectual property can be respected, while eBooks files are transported easily and without unneeded restriction.
This would improve the current situation a lot, as we have the situation today, that copy protection and other sorts of digital rights management severely impede eBook sales and transfers.
eBook piracy and its counter-measures
A common problem in eBook trading today is eBook piracy. It is easy for an experienced person to remove copy protection from eBooks. Then the unencrypted eBook is sold for a fraction of its legal price in the darknet. Or it can be downloaded in file-sharing networks for free.
Digital rights management (DRM) is also known to harm eBook trading in many ways.
In order to prevent illegal copies, eBooks are often distributed in encrypted form. In these cases, decryption and readability is restricted to specific hardware (eBook-Reader), or to specific software. As a consequence, readers are deprived of a lot of flexibility. Almost always there is no way for them to give away or resell an eBook. Forming collections, storing eBooks, conversions between eBook formats, using different reader software or hardware, any of these activities are either impossible or confined to the “jail” provided by the seller.
This seems to be an almost unsolvable problem, as no way can be thought of to completely remove the possibility to create a readable copy of an eBook and spread it on the internet. With more or less effort it will always be possible to copy an eBook, i.e. to “de-DRM” it.
A new incentive must be given to readers in order to motivate them to buy an eBook legally, even if this is more expensive than an illegal copy.
We are convinced that such an incentive can be found, based on the fact that the current situation on the eBook market is not satisfying, neither for readers, nor for publishers, nor for editors. The situation could be improved in many ways so that trading of eBooks becomes less complicated, more transparent and less restricted to specific software or hardware.
As soon as these drawbacks will be removed and a better eBook market will become possible, there will be many advantages in this for all parties involved.
In a legal and transparent eBook market trading will be easier, and this will be the first incentive for people to buy and sell in a user-friendly, open market. Prices could go down because transactions are simplified.
Secondly, we believe that there is a motivation by the majority of people to behave well. No society would function if this were not the case for many of us. So we do believe that many people would be interested in legally possessing a digital asset, and this is why they will prefer a legal copy to an illegal one, if they have the choice, and if it is made easy for them to choose.
But at the moment, such a choice does not really exist for an honest person. Legally bought eBooks are not really a possession. What you really get, buying an eBook, is just a “right to read”. This right is commonly restricted by long and complicated terms and conditions, different for each vendor. More restrictions stem from vendor-specific hard- and software.
So there is, in fact, an incentive to use illegal eBook sites, and it is difficult to argue in favor of legal trading.
But we will now develop our concept to improve this situation …
eBooks in the blockchain
The smart contract
One of the programming languages currently being developed to describe smart contracts is called solidity. The code example below is written with the intent to resemble code written in solidity, but it is in fact pseudocode. Its purpose is to illustrate the (very simple) programming logic inside a smart contract to trade an eBook.
contract Book {
uint minPrice; // price of the book
string eBookHash; // hash identifier of the book
address author; // author of the book
address editor; // editor of the book
address shop; // shop selling the book
uint copies; // number of copies to be sold function fee(address who,uint aValue) returns (uint aFee){
//Calculate the percentage of the paid price that needs to be sent
// to the address
[...]//Implementation skipped
return aFee;
} //Transfer a digital copy to another smart contract
function transferCopyFrom(address otherContract){
[...]///Implementation skipped
}
function buy(){
if(msg.value < minPrice) throw; //Not enough money sent, abort. if(copies < 1 ) throw; // This book is sold out //Pay the parties involved, according to the contract negotiated
author.send(fee(author,ms.value))
editor.send(fee(editor,ms.value))
shop.send(fee(shop,ms.value)) //Reduce the number of available copies
copies = copies -1 }}
In our simple trading scenario, the following actors will play:
- Author
- Editor
- Shop
- Reader
The following explanations require a basic understanding of public key cryptography. We call a system using public key cryptography for encryption, decryption, authentication, and authorization a public key infrastructure (PKI).
Each actor in our scenario will be provided with a private key that can be used in elliptic curve cryptography. This private key can be used to calculate the corresponding public key, while the reverse process is not possible. And then the public key can be used to calculate a blockchain address, which corresponds to a short string of about 33 characters.
- The blockchain address can be used to uniquely identify the actor.
- The actor himself, as he knows his private key, can use it to sign data, thus producing a digital signature.
- Anybody in possession of the actor’s public key can use it to verify any digital signature produced by the actor.
So, every actor in the market will be provided with a blockchain address. He can thus be identified by his blockchain address, and he can use the private key of his address to produce digital signatures for arbitrary data.
Unfortunately, key pairs based on elliptic curve cryptography are not good for encrypting and decrypting data (though in principle this is possible, but not practicable). This is why for encryption and decryption we will need a second key pair, for example, an RSA key pair. This key pair will be used for encryption and description.
As we will use this second key pair for eBook transfer, we will call the corresponding infrastructure our transfer PKI. Its public key will be the transfer public key, and the private key the transfer private key.
On the other side, we will call the private key corresponding to our blockchain address our blockchain private key. The public key will be called the blockchain public key.
And now we will perform the following steps:
- The owner of the eBook will use his transfer public key to encrypt the eBook.
- Every actor will use his blockchain private key to sign his transfer public key
- The owner of the eBook will add the encrypted eBook file to the file sharing network, and he will, in turn, receive the hash code that uniquely identifies the encrypted eBook file.
Step 2 is crucial to couple the blockchain network with the file-sharing network. We will learn about the benefits of this action in the following section.
The hash created in step 3, will be used to set up the smart contract.
Now this hash and the blockchain addresses of the four actors involved can be used to deploy a single instance of the smart contract into the blockchain network.
As soon as the smart contract is deployed, eBook trading can begin.
For example, if a reader (for example Linda) buys the book “The Shining”, by Stephen King, the following will happen when the smart contract is invoked inside the blockchain network:
- A blockchain transaction is executed, that transfers the amount of money (equal to the price of the eBook in a cryptographic currency) from the account associated with the reader address (Linda’s address) to the smart contract.
- The smart contract calculates the fees and transfers the corresponding percentage of the eBook price to the author, the shop and the editor.
- The copy counter inside the smart contract is decremented by one.
Of course, decrementing the copy counter can be optional, as it is possible to produce an unlimited number of copies of an eBook. But we think that such a counter does make sense, as scenarios can be possible, where limiting the number of (legally) available eBooks could be useful because this could lead to higher prices and higher demand.
The transaction server
As the smart contract only contains the logic directly related to eBook sales, a second component is needed to provide user interaction. This component must be linked to the eBook shop providing the shopping frontend, and we will call it a transaction server.
But no matter how you call and implement it, it will always have to provide the link between blockchain transactions and the rest of the world. In our example, it would simply have to receive sales data from the eBook shop and trigger the eBook transaction inside the blockchain network.
eBooks in the file sharing network
The request
Now that Linda has bought the eBook, she has the right to receive it via the file-sharing network.
The provider of the eBook will have to send a copy to Linda in such a way, that he can be sure that only Linda can read the book, and that he can be sure it is really Linda receiving the book, and nobody else.
Let us assume that the eBook is provided by an eBook shop. (Of course it could also be provided by the author himself, or by the editor or by anybody else participating in the eBook market using the infrastructure described above).
Furthermore, in the following we will assume that the file sharing network in use is IPFS 1. This also means, that the hash of the eBook is equal to the hash generated by IPFS when the encrypted eBook was added to the sharing network as described in the previous section.
IPFS is used to simplify the explanation, but the principle behind this can easily be transferred to other file-sharing networks: The basic idea is just to use the signatures that can be generated with the blockchain addresses to authenticate and authorize in the file-sharing network.
We will assume, that there is a directory in IPFS, that can be found using Linda's blockchain address. This directory will have to contain Linda’s transfer public key, and her signature, created as explained in the previous section.
The shop will now have to maintain a content server that can handle the following steps:
The shop’s content server will receive Linda’s eBook request.
This request needs to contain the transaction hash that uniquely identifies the eBook transaction executed in the blockchain when Linda bought the book.
Using this transaction hash, the content server will be able to retrieve all the information needed to process the request:
- Lindas blockchain address
- The hash of the eBook
The transfer
Using the blockchain address, the content server will now be able to find Linda’s directory in IPFS. There it will find Linda’s transfer public key, and Linda's signature. Using Linda’s signature, the content server will be able to verify that the public key is really owned by the person that bought the eBook in the blockchain, i.e. Linda.
The rest is straight forward. The content server will use the shop’s transfer private key to decrypt the eBook. Then it will immediately encrypt it using Linda’s transfer public key and write the file into Linda’s directory.
Linda will find the eBook in her directory, and — as she can decrypt it with her own transfer private key — she will be the only one to read it.
But as discussed in the beginning, Linda can still create and distribute illegal copies of the eBook, as long as she fully controls her private key and knows how to use it. Different scenarios can be conceived, if Linda does not directly work with her private key, but uses an eBook reader software or hardware. In this case, Linda would again end up with conventional DRM and all its drawbacks.
Resales
In the example above, Linda cannot resell her copy of the eBook, because she herself is not the owner of the book contract. She just received the right to read by paying money to the contract.
For her to own a tradable copy of the eBook, she needs to deploy a second instance of the smart contract, in which the copy counter will be initially set to zero.
She will get the right to resell the book by paying a transaction having the original smart contract and her own smart contract as endpoints. This transaction will be executed by calling transferCopyFrom(...) on her own instance of the smart contract. The function declaration has been given in the code example above for illustrative purposes.
Buy this transaction involving two smart contracts, the copy counter of the first smart contract would be decremented by one, while Lindas copy counter would be incremented by one.
Of course the price of this transaction could be higher, as Linda receives in this case a tradable good, which could be validated higher than a simple right reading right.
Apart from resales, much more complex scenarios are getting visible now: There would be almost unlimited possibilities, if the complexity of the contract’s definition were increased, or more actors were involved in trading.
Closing
It is obvious that the principles described above are not limited to eBook trading. In fact they could be easily extended to describe trading of an arbitrary digital asset. But as most of the concepts used in the document are fairly new and fairly abstract, it seemed to be good to start with a concrete example. The future will show if variations or extensions of the concept will thrive.
