Contracts on the BlockChain

Posted: July 20, 2016 in Work Stuff

Introduction

Initial investigations into using the Ethereum BlockChain were targeted towards the use of Smart Contracts.

These Smart Contracts have the potential to help my employer manage entitlements and digital/asset rights without requiring a single point of approval.

The Contract

As a paper based exercise prior to trying to convert the theory into practise, the following three contract types have been considered.

  1. Generic shop
  2. Asset based
  3. Customer based

As Ethereum contracts come with basic storage capabilities it allows us to store data in a way defined by us within the contact. This can be anything from simple key-value pairs through to complex structures.

The contract would then store the information about the transaction depending on the contract type – the customer, the asset and any access rights associated with the transaction in its storage.

Playback would depend on checking that the user requesting the asset on the current device meets any access rights. Success would allow the player to continue, failure would cause playback to stop with an appropriate message.

In the case of the generic shop contract, the assumption is that there would be a single version of this contract on the BlockChain that then handles the duties for the entire marketplace.

For asset based contracts, each asset could have its own contract deployed on release to the marketplace. Each transaction for that asset would be stored in the contract.

For customer based contracts, each customer would have an account contract deployed on signup that then contained a list of available assets.

In all three scenarios, the assumption is that contract storage would be used to store the relevant information. However, if the contact is part of a private BlockChain, it could add blocks to that BlockChain rather than using contract storage.

In either case, storing information back to the BlockChain – either in contract storage or as blocks – has a cost associated with it that is proportional to the amount of data to be stored.

Each version has its benefits and drawbacks as outlined below.

Generic Shop Contracts

A generic contract like this acts as the central store in the asset lifecycle. The system would allow Customers to sign in with their account address (allowing access to the customer’s wallet) and then handle the transaction between the buyer and seller of the asset.

This would then allow for both open purchases, limited purchases (time, device, resolution and/or playback limits) as well as rentals or downloads.

Pros
1. Potential for single contract for all transactions.
2. If necessary, each Provider could extend the basic contract via inheritance to enable additional access rights that are relevant to them.

Cons
1. Would require extensive storage within the contact.
2. Speed of searching the storage to find a match could be detrimental to playback.
3. Single point of vulnerability – contract would need to be complex to handle all provider requirements.
4. Adding new requirements or providers could be problematic.

Asset Based Contracts

These contracts are associated with a specific asset or title. It would allow for a contract that holds the basic asset information that can then be extended by using inheritance to add contracts for specific versions or use-cases.

The provider can modify the contracts to better reflect their actual requirements on a per asset basis. New or popular titles can have tighter requirements. As assets get older, new contracts can be issued that reflect the changes.

 Star Wars
    |\
    |  \___ Star Wars UHD
    |   \
    |    \___ Star Wars HD
    |   
Star Wars SD        

Potentially, the entire contract could be updated allowing existing owners to benefit without changing individuals. For example, if the SD version was no longer available, all the current SD owners could be migrated across to the HD version without any action on their part.

The sale of the asset would need to be registered within the storage of the associated contract.

Playback would require searching the relevant asset contract for permission to proceed.

Pros
1. Allows for fine control over assets.
2. Can deploy multiple contracts & sub-contracts to limit risk of exposure or speed up validation searches.
3. Can revoke entire contract or sub-contract if asset security breached.

Cons
1. Lots of storage if asset is popular.
2. Speed of searching through storage.
3. More management for providers.

Customer Based Contracts

These contracts are associated with a specific customer. It allows for a contract that holds basic information about the customer. If necessary, the providers could extend this info via sub-contracts to ensure that they had information relevant to their access requirements.

 Customer Account
   |\ 
   |  \___ Studio 1 Account
   |   
  Studio 2 Account

Pros
1. All customer’s assets in a single storage tree.
2. Quicker rights searches.
3. Single master account for all providers.
4. Potentially easier to validate all assets on start-up allowing for status messages/alerts and removal of expired assets.

Cons
1. Customer loses the account, loses all the content.
2. Assumes all providers use the same system.
3. Account breached, all content exposed.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s