W H I T E P A P E R

J U L Y 2 0 1 8v 9 . 3 . 4

TransmutePlatform A rapid application development framework for

centralized, decentralized and hybrid Ethereum

applications and services.

This document is for informational purposes only and does not constitute an offer or solicitation to sell shares or securities

in Transmute Industries, Inc. or any related or associated company. Any such offer or solicitation would only be made by a

confidential offering memorandum and in accordance with applicable securities and other laws. Transmute Industries may

make changes to this White Paper at any time. Please visit Transmute.Industries for the most recent version.

0 1

02 Abstract

02 Introduction

04 Transmute Protocol

14 Decentralization

16 Summary

16 Appendix

19 References

04 Infrastructure

04 Packages

11 Verification of Work

04 Transmute Platform

04 Features

05 Minerals

11 Token Rewards

12 Slashing

12 Token Distribution

12 Governance

12 Attacks and Faults

05 Roles

06 System

06 Transmute Token (TST)

07 Role & System Diagram

07 Providers

07 Consensus

08 Bonding & Delegation

08 Provider Transaction

09 Consumer & Provider Job

15 Use cases

16 Transmute Protocol Parameters

17 Transmute Protocol Transactions

05 Common Properties

05 Storage Properties

05 Compute Properties

05 Security Properties

13 Ethereum Consensus

13 Network Misconfiguration

13 Denial of Service

14 Useless Work

14 Central ized Failure

15 Decentral ized Blog

15 Decentral ized Exchange

15 Decentral ized Supply Chain

15 Decentral ized PaaS

09 Preprocessing

10 Job

10 End Job

11 Regarding Truebit

Table of Contents

AbstractThis document and the associated technologies are under development and subject to change.

The Transmute System, comprised of the Protocol, Platform and Framework provides a self-scaling, pay-as-you-go network for applications to be deployed to and consumed from, while supporting a compatible deployment environment in centralized cloud providers.

The Transmute Platform enables developers to quickly build applications and services that integrate centralized and decentralized components. By combining existing cloud computing industry standards with blockchain and peer to peer technology, Transmute allows developers to substitute both centralized and decentralized tooling, technologies, and hosting solutions. Our platform provides the gold standard for web3 development by combining decentralized token based incentivization with modern cloud computing, offering developers the flexibility to easily deploy applications to hybrid, decentralized, and centralized backends. In this paper we describe the Transmute Protocol: a delegated stake-based protocol for incentivising secure multiparty computation and hosting in a game-theoretically secure manner. We demonstrate solutions for transparent substitution and integration of centralized and decentralized application components and describe our resilience to attacks in both centralized and decentralized scenarios.

IntroductionModern application development is powered by a fusion of servers, databases and programs hosted on centrally managed public and private clouds. Many enterprises and small businesses have migrated onprem solutions to Amazon, Microsoft, and Google in order to leverage the scalability, security, and support that these vendors compete to provide. However, centralized hosting, computing, and distribution infrastructure faces many threats including, surveillance, censorship, theft, and coercion. As the Internet has grown, it has centralized for convenience and cost, leaving the security of the system entrusted to a handful of corporations and governments. Simultaneously, advances in the performance of asymmetric cryptography coupled with a relaxing of export control laws drove the advent of secure decentralized systems.

Decentralized solutions for currency, computation, and storage offer cryptographic and economic experiences that are unique, valuable, and impossible to replicate in a centralized environment. However, most existing enterprises are already heavily invested in centralized cloud providers and their associated security models. Increasing scrutiny of vulnerabilities inherent in centralized systems along with impending competition from decentralized players is compelling businesses to figure out how to leverage the security gains that blockchain. The safest initial step forward is that of the hybrid application , where decentralized components are integrated to enhance centralized systems in the near term.

Unfortunately, developing complex applications that interface with both centralized and decentralized systems is difficult. Developing hybrid applications is challenging due to the growing number of potential technologies, early nature of projects, limited documentation and separate steep learning curves. Moreover, best practices, tooling, technologies, frameworks, and modern cloud architecture patterns are in the process of being established. Effective hybridization means centralized concepts like web servers, databases, and web applications must interface with decentralized filesystems, messaging systems, and ledgers in order to leverage the security properties of decentralized systems.

0 2

Transmute Network Role Diagram

This whitepaper focuses on the crypto-economical implementation of the platform, rather than the business case. In summary, there are no established development environments which support rapid application development and translation between centralized and decentralized backends. By solving this problem, the Transmute Platform makes hybrid application developmentfaster, safer and simpler.

Some components of the Transmute Platform such as smart contracts and the event sourced framework are available separately, but until now, there has been no incentive to encourage users to develop and host a platform which specifically integrates the solutions of major cloud providers with decentralized self sovereign cloud computing.

This incentive is provided by the Transmute Token mechanics. Token-powered protocols [1] allow for financing the development of an open platform for hybrid application development while incentivizing users to develop and contribute to the delivery of self sovereign computing infrastructure.

Developers can optimize for confidentiality, availability, performance and cost by leveraging the best of centralized and

Users can build applications quickly using documented abstractions for common application building blocks.

Nodes running the decentralized application fabric will host these applications, and the operators of these nodes will be rewarded with fees paid by application developers and consumers as well as newly minted Transmute Protocol tokens (TST).

Enable any node to be compensated for providing access to minerals, by providing computation or storage.

As the Transmute Platform is developed:

—

—

—

0 3

DApp

Pay TST to Publish compute and storage jobs to the network.

Delegates/Providers

Earn TST for Managing access to compute and storage minerals

DApp Users

Pay TST to access Dapps and interact with them

Transmute Industries aims to support modern web and mobile development, but may choose to expand our abstractions and support to embedded and native applications in the future. Web browsers allow for rich applications to be easily developed and shared. The Transmute Platform relies on JavaScript, and can be used to develop applications that leverage many web technologies. The Platform makes use of several infrastructure technologies, including Kubernetes and OpenFaaS, to provide a common operational language for Providers and Consumers.

Transmute Platform

Features

The Transmute Protocol defines how users in a decentralized cloud network interact economically and securely. The protocol has two key responsibilities: 1) the actual distribution, hosting, and execution of application code in a scalable and secure manner, and2) the economic incentives for game-theoretic security properties of the network. Due to the rapid evolution of infrastructure technologies, this paper will focus on 2. For 1, see [1-6] for related white papers.

Infrastructure

The Transmute Platform provides a simple interface for managing standalone services, reviewing analytics, and performing backups. In addition to services such as hosted IPFS and Ethereum nodes, Transmute provides hosted versions of the decentralized platform to help users get up and running quickly.

Packages

Built with IPFS and Ethereum, the Transmute Package Manager is at the core of the platform and is used to publish and manage decentralized applications and services. The package manager can also be used to manage secrets, which enables developers to easily implement integrations with centralized providers using APIs based on the client-server security model.

The Transmute Package Manager can be used in public and privateconfigurations, and provides developers monetization opportunities fordeveloping popular services or infrastructure.

Transmute Protocol objectives:

Enable any node to create a mineral (unit of work) corresponding to storage or compute.

Enable any node to access a mineral from the network. This corresponds generally to requests for computation or storage.

Enable any node to be compensated for providing access to minerals, by providing computation or storage.

—

—

—

—

—

As nodes are rewarded for the work they perform for the network, we must address two security related topics:

Whether the work be verified and proved correct.

Whether the nodes are performing work that is valuable to the network [versus attempts to game the system to acquire rewards without providing value].

Transmute Protocol

0 4

The Transmute Protocol is designed to address both concerns, while supporting the governance of the protocol evolution to achieve scalability and additional features.

We define the unit of work in a decentralized cloud as a mineral of type: compute or storage. Subtypes may be added in the future to enable more fine grained technology-specific support. Each mineral contains some common metadata, type properties, security properties and economic properties. We further limit the initial mineral types to computation provided by OpenFaaS [16] and storage provided by IPFS. Developers deploy minerals by publishing to the network, and users access minerals through the Transmute Protocol and the work done by providers.

The Transmute Protocol describes how computation and storage are published and consumed from the network.

Minerals

Each interaction with a node is always in the context of a single role. Certain actions like providing and verifying can be automated and may not require a user to actively participate. A Transmute node is any computer running the Transmute Platform.

Roles

Guid A string encoded globally unique identifier.

Type A string representing compute or storage work.

Data_hash A sha3 of the binary data.

Common Properties

Property Name Description

Data A binary data to be stored.

Price A binary encoded object representing the price and conditions this creator is willing to accept for storage work.

Storage Properties

Property Name Description

Data A binary input data for a computation.

Price A binary encoded object representing the price and conditions this creator is willing to accept for compute work.

Compute Properties

Property Name Description

Signature A signature from the mineral creator of Priv(guid, hash(guid, data)) which can be used to attest and verify that the creator claims this to to be the true data for this mineral.

Security Properties

Property Name Description

0 5

The Transmute Platform is built on top of several technologies to support centralized and decentralized cloud development and deployment. The platform is specifically designed to support the substitution of sub systems with compatible APIs or for which a secure and economical adapter can be developed.

An initial allocation of Transmute Tokens (TST) will be distributed to key stakeholders and early network operators. Additional tokens will be issued on a predictable inflation schedule. See the Token Distribution section.

Systems

The Transmute Token (TST) is the protocol token of the Transmute Network. The token is ERC20 compliant and divisible by 10^18, with large denominations reserved for user transactions and staking and smaller denominations for fees and internal operations. Consumers use TST to publish minerals to the network, and consumers pay TST to access those minerals. Nodes who contribute to the delivery of minerals earn TST in the form of fees from Consumers and rewards from the newly minted token. The token has the following uses in the network:

Transmute Token (TST)

TST serves as the fuel for creating minerals on the Transmute Network.

TST serves as a bonding mechanism in a delegated proof-of-stake system where stake is delegated towards providers and verifiers who participate in the protocol to provide the mineral functionality.

TST is a unit of account in the Transmute Network corresponding to the ability to interact with minerals representing compute and storage.

—

—

—

Consumer A user is a consumer when they access a mineral on the network.

Delegator A user or node who bonds their token to a provider in order to receive a portion of the work reward. See Token section.

Provider A user or node is a provider when they support the access of a mineral by a consumer.

Producer A user is a producer when they deploy minerals to the network.

Type Description

Ethereum A blockchain application platform that supports smart contracts and payments.

OpenFaaS(Functions-as-a-Service)

A user or node who bonds their token to a provider in order to receive a portion of the work reward. See Token section.

TNSC(Transmute NetworkSmart Contract)

A smart contract running on the Ethereum network used to govern and administer the Transmute Token (TST).

IPFS A peer-to-peer hypermedia protocol to make the web faster, safer and more open.

Truebit Blackbox verification protocol that guarantees correctness of computation placed on chain. [7]

Name Description

0 6

Role / System Diagram

This diagram describes the interactions among users, nodes, roles, and systems as they coordinate their efforts to perform the work verification process described below.

Role & System Diagram

Providers play a critical role in the Transmute Network, as they are responsible for the quality of minerals delivery to Consumers. As such, they benefit from professional computing infrastructure, especially in the early stages of network growth. We expect many Providers will be hosted on centralized public clouds such as Amazon, Google and Microsoft. In order to ensure stability, Providers must not churn too frequently; frequent churn eads to service disruption for mineral Consumers. The scalability of thenetwork is tightly coupled to the number of Providers, which aligns with the reward mechanic. This role is delegated from most network participants in order to guarantee value to creators and Consumers.

Providers

The Transmute Network has two core layers of consensus. The first is derived from the underlying smart contract supporting blockchain (Ethereum). Any transfer of TST or Transaction in the system is confirmed according to the security properties of proof-of-work or proof-of-stake within the underlying smart contract supporting blockchain. The second layer dictates the distribution of newly minted TST. This is governed by the Transmute Network Smart Contract and participation by actors (nodes and users). The protocol does not require consensus, but defines the rules for participation and the rewards and penalties (slashing) for passing or failing role fulfillment. Delegated proof-of-stake (DPOS) used to secure the second layer ofconsensus is inspired by systems like Casper, Bitshares, Tendermint, Steem and Livepeer [1, 10, 9, 11, 2 ]. The role of validators in the network is played by Providers. Any user can delegate their stake towards a Provider who needs to perform the work described by a mineral, participate in the work verification protocol, and invoke methods on the Transmute Network Smart Contract at specific intervals to validate work and reap rewards. The validation results are recorded on-chain via Truebit to mitigate disputes between providers and Consumers.

Consensus

0 7

51 Consumer C creates a job

request J on chain and places some TST in escrow to cover the cost of the work. provider P is assigned.

2 C sends requests to P with signatures for verifying the input data.

4 P writes the input data needed to perform verification to IPFS ensuring that the data will remain available for VerificationPeriod time.

On chain call to the Truebit smart contract, where the P provides the IPFS input has for the challenged segment.

7 Truebit writes result of J on chain and compares with the provider claim result provided by P.

3 P performs work and stores receipts for work. Claims work for J on chain and submits a merkle root of all the receipts to commit to the content of this job.

6 Truebit uses IPFS input hash for challenged segments for offchain verification.

Consumer Provider

TNSC

Nodes indicate their stake in the Transmute Network by bonding some amount of TST. They do this by locking up their TST through the Bond() Transaction on the Transmute Network Smart Contract, until they Unbond(), at which point they enter an unbonding state lasting for UnbondingPeriod time, at the end of which they can withdraw their TST.

The bonded amount is used to delegate stake to the Provider. The network supports an adjustable N number of active Providers at one time. Any node can indicate that it wishes to become a Provider with the Provider() Transaction, and the protocol will select N Providers with the most cumulative stake (including delegated stake) at the start of each round and one from waitlist.

Newly minted TST in the network is distributed to bonded nodes in proportion to the amount bonded less fees, so long as the nodes have delegated towards nodes that successfully fulfill their Provider role. Bonds can be reduced by a percent (slashed) if the nodes delegated towards fail to fulfil their Provider role by violating one of the slashing conditions. Nodes who have bonded and delegated towards a Provider who fulfils their Provider role receive a portion of the fees earned through the successful completion of work.

A ‘Delegator’ refers to bonded nodes who have delegated their stake to a provider candidate, instead of delegating towards themselves as a Provider.

Bonding & Delegation

A node indicates its willingness to be a Provider by submitting a Provider() Transaction to the Transmute Network Smart Contract, which contains the following public properties:

The Provider can update their availability and pricing up to RateLockDealine time before the next Provider round. For example, they change this information 3 hours before the next Provider round which lasts RoundLength (1 day for example). The evaluation period enables bonded nodes to review Providers’ offerings relative to each other and make adjustments to their stake if they wish. An InitializeRound() Transaction starts the next Provider round and the active Providers are determined from the total stake delegated to each Provider; stakes and rates are locked for the duration of the round.

Provider Transaction

Delegating towards effective Providers ensures value is delivered to Consumers.

Earn Transmute Token (TST) rewards in proportion to stake.

Earn fees generated by Providers.

Act as a Provider.

PricePerMineral: the lowest price they are will to accept for each mineral price condition object configuration.

BlockRewardCut: the percentage of the block reward that bonded nodes will pay this Provider for successful role fulfillment.

FeeShare: the percentage of the fees from providing mineral work that the Provider is willing to share with bonded nodes who delegate towards it.

For example: 3%. If a bonded node were to receive 100 TST block reward, they would pay 3 TST to the Provider.

For example 25%. If a Provider were to receive 100 TST in fees they would pay 25 TST to bonded nodes.

—

—

—

—

Bonding Motivation:

—

—

—

—

—

0 8

Providers announce their availability by submitting ProvideAvailability() Transaction to the Transmute Network Smart Contract. This places the provider in a pool for available work. When a creator or Consumer submits their mineral or access request for amineral into the network it is given a guid and the network address of the creator or Consumers is recorded to allow for direct communication with a provider. A job is created on the Transmute Network Smart Contract to represent the relationship between the Consumers and Providers. Roughly:

Job(JobID, ProviderOptions, PricePerMineral)

The ProviderOptions represent the Consumer’s preferred mechanism for consuming the work conducted by Providers.

Once this transaction is mined, the next blockhash will be used to pseudo randomly determine the Provider(s) selected for this job. All Providers with compatible parameters (price and conditions) will be considered, and the blockhash combined with the acceptable candidate Providers weighted by their stakes will determine the selected Provider(s).

At this point the Consumer can begin to access the mineral through the selected Provider(s), according to the following protocol. The protocol makes use of IPFS for work verification.

Here is an example Provider options list for Delegators to choose from when deciding how they should delegate:

* Note: PricePerMineral is a list made of 2 separate price and condition pairs corresponding to the conditions and prices being offered for compute and storage.

** Note: PricePerMineral is a stand-in for a generic representation which will more efficiently communicate the finer-grained price for quality and parameters of the service being provided. Providers will use IPFS and OpenFaaS to conduct work for consumers (storage and compute). Analytics will be used to improve the pricing configuration as the platform evolves.

Consumer & Provider Job

1 22 μTST, 10 μTST 1% 25%

2 10 μTST, 20 μTST 2% 35%

N 2 μTST, 2 μTST 0% 2%

... ... ... ...

Provider ID PricePerMineral * BlockReward Cut FeeShare

Preprocessing

Consumer > TNSC

A Consumer submits a deposit on chain to cover the full cost of providing access to the requested mineral. This can be refilled later, but a Provider will stop working if the deposit runs out.

0 9

Job

Consumer > TNSC : Job(guid, options, price/mineral)

Consumer creates a job request on chain and places some TST in escrow to cover the cost of the work.

The protocol deterministically selects the Providers(s) for this job.

Provider > TNSC

The Provider sends a job output guid and receipt that the job was accepted.

Consumer > Provider

Consumers sends requests to the Provider with signatures for verifying the nput data.

Provider performs work and makes output available on network via job output guid.

Provider stores receipts for work. They have the following fields:

job_input_guid A string encoded guid.

job_output_guid A string encoded guid.

input_data_hash A hash of input data.

output_data_hash A hash of output data.

consumer_mineral_signature A signature from the consumer of Priv(JobID, data_dash) which can be used to attest that the consumer claims this to be the true data for this job.

provider_mineral_signature A signature of the above fields used by the provider attesting to the claim that job output was the result of performing this work.

Name Description

When a Provider observes that a consumer has provided the full job description, they can call ClaimWork() to claim the reward for work completed.

End Job

Provider > TNSC: ClaimWork(JobID, …, MerkelRoot)

The Provider claims on chain that they have performed the work for the job and submits a merkel root of all the receipts to commit to the content of this job.

Wait for the transaction to be mined and observe the next blockhash. The protocol can then determine which minerals should be verified based off VerificationRate.

Provider > IPFS

Provider writes the input data needed to perform verification to IPFS ensuring that the data will remain available for VerificationPeriod time.

1 0

Provider > TNSC

Provide job claims on chain for each mineral that needs to be verified, along with merkel proofs for the receipts for each mineral in the claims.

The contract can verify signature from Consumer and Provider to ensure all necessary data is available for verification and can verify the merkel proofs against the committed merkel root from ClaimWork().

Provider >Truebit: Verify()

An on chain call to the Truebit smart contract, where the Provider provides the IPFS input hash for the challenged segment. (See verification of work).

Truebit > TNSC

The result of the job is written on chain and compared with the Provider claim result provided by the Provider.

There is now sufficient information to for TNSC to verify the Providers work. If verification passes, the token reward algorithm is triggered and escrowed funds are released.

If verification fails, the Provider and its stakes get slashed FailedVerificationSlashAmount, and Consumer is refunded.

The Consumer can request the job end early, which is effectively an EndJob().

At this point the Provider has delivered access to the mineral to the Consumer and proof-of-work has been claimed on the chain. All information necessary to determine allocation of fees and newly minted TST tokens to Providers and Delegators.

We rely on the Truebit protocol [8] for verification of work claimed by a provider. Truebit works by having one solver perform the actual work for the fee - in this case providing access to a mineral - and subsequently have verifiers verify the work to detect mistakes, errors, or cheating. The work is broken down into small steps where the verifiers check the work of the solver for the first deviation. Then this small step is replayed on the chain by a smart contract judge who can tell which party performed correctly. Clever economic incentives, including forced errors, ensure that it is not profitable to cheat or challenge; meanwhile, it is profitable to play the role of checking work.

The Truebit protocol is expensive, but cost can be reduced by randomly selecting a limited number of challenges and relying on slashing to discourage cheating. The VerificationRate set within the network along with randomness of future block hashes determines which challenges are selected.

If work is committed via ClaimWork() call in block N, then:

According to the rules of the verification game, parts of the mineral access that were included in block N are chosen for verification pseudo randomly according to this general expression:

If Sha3(N, Blockhash(N), WorkChunkNumber) % VerificationRate == 0, thenWorkChunkNumber must be verified.

The Provider provides claims on chain for the candidate work chunks by invoking the Verify() Transaction. The TNSC can verify the authenticity of claims using signatures and merkel proofs and then a call to Truebit to verify specific WorkChunkNumbers.

Verification of Work

1 1

Truebit solves and verifies access the input data for a WorkChunkNumber from a persistent content addressed storage system; in our case, IPFS. The Provider is responsible for verifying that the mineral access data is available in IPFS and can verify that the data will be available long enough for verification to be completed. Providers can run their own IPFS node to ensure data availability, and improve performance on certain mineral jobs.

Truebit will notify TNSC of the success or failure of a verification which is input to the reward and slashing operations of the protocol. A Provider cannot predict in advance which mineral access indices will be verified, and the following penalties are enforced when failure is detected:

Careful configuration of slashing parameters and verification rate is necessary to ensure that it is more profitable to stake TST towards honest Providers than it is to cheat and take slashing penalties while collecting fees and rewards for dishonest work.

FailedVerificationSlashAmount will be slashed if they fail a verification from Truebit.

MissedVerificationSlashAmount will be slashed if they fail to provide claims necessary for verification.

Lost fee from Consumer.

All Delegators will be slashed, and will most likely not choose to delegate to a Provider who consistently fails.

—

—

—

—

—

—

—

—

—

—

— Centralized Verification Oracle - Trusting a public cloud oracle to verify work is ideal for testing and appropriate for certain private chain use cases.

Oraclize Computation Service - Trusting a company who focuses on truthful verification to perform the operation.

Secure Enclaves - Leveraging services such as Intel SGX that provide trusted computing environments which can be audited.

Regarding Truebit

Verification of work in this manner is expensive, and alternative verification methods or hybrid approaches may be implemented in the future. In order to ensure an efficient network, we propose alternative configurations for private use cases:

The Transmute Token (TST) is inflationary and new tokens are minted according to the schedule Token Distribution. Newly minted TST are rewarded to users in proportion to their bonded stake less fees. Providers are required to call Reward() in order to trigger their reward or slashing according to the data available on chain. Each Provider is required to call Reward() once per round, the TNSC will verify the following:

Token Rewards

Ensure that an active Provider is calling Reward().

Ensure that the Provider has not called Reward() this round yet.

Compute and mint the number of tokens to be minted based on InflationRate.

Calculate the Provider’s cut based on their BlockRewardCut.

Distribute this into the Provider’s bonded stake.

Distribute the remainder into the Delegators reward pool.

Update the bonded amount of token to the Provider

—

—

—

Failure to invoke Reward() results in a loss for both Provider and bonded Delegators. It is not rational for Delegators to bond to a Provider who fails to claim rewards often.

1 1

The conditions for slashing are:

There are two core goals for protocol governance:

Slashing

Token Distribution

Governance

Failing a verification

Failing to invoke verification when required

Not performing a proportional amount of work based on delegated stake

—

—

—

Determining the burning or appropriation of TST collected through slashing.

Adjusting network parameters to ensure value is provided to Consumers.

—

—

Care must be taken to ensure correctness of dependencies, because it is possible that failures in the underlying technologies of Ethereum, Truebit, or IPFS could cause a failure and trigger slashing.

Node operators are incentivised to host functioning dependencies to reduce the risk of being slashed, but thresholds such as VerificationFailureThreshold can be set as a last resort to allow some percentage of verifications to fail without triggering slashing.

Failure to invoke verification can be triggered by any network participant and a FindersFee that represents a percentage of the slashing fee to be provided to the finder incentivizes accurate reporting.

The remains of the slashed TST will be deposited in CommonPool, which can be regularly burned or allocated as needed to support optimal network operations according to the governance protocol.

An initial allocation of the tokens will be distributed to people purchasing it to become Providers or Consumers or to stake into the role of Provider or Delegator. The proceeds of the sale will be used to fund the development of the protocol and commercialize the Transmute Platform. A portion will be allocated to early contributors and investors, and a portion will be endowed to a foundation in order to support ongoing development of the open source software powering the Transmute Platform.

From the launch of the Transmute Network, supply will increase according to an inflationary schedule, with new tokens being minted at InflationRate % of initial issuance per year. Because token issuance is in proportion to bonded stake of all participants, it serves to incentivize active support of the network. Transactional users should not hold TST for long enough to be adversely impacted by the inflation, and active participants are protected due to their proportional reward.

The initial target for InflationRate can be adjusted via governance, and will be set to encourage at least 50% of the TST to be bonded for active participation and 50% liquid for transactional use. Higher rates encourage additional tokens to be bonded creating more supply, while lower rates encourage users to create additional demand by developing

1 2

Ethereum Consensus

Because primary consensus is managed by Ethereum, 51% attacks, double spending, and network forking have the same attack cost as they do in Ethereum.

Similar network phenomena like chain reorgs and forks can be resolved as they are on Ethereum: with the adoption of new code through the governance mechanisms available.

It is important to note that changes to Ethereum, such as proof-of-stake, impact the Transmute Network. We are relying on the same security properties as Ethereum, and therefore, the benefit in ETH and TST must not exceed the cost of the attack.

Network Misconfiguration

Generally, the protocol is secured by the careful configuration of network parameters such that it remains more profitable for Providers to be honest than to cheat. The slashing and reward mechanics combined with proportional inflation ensure this property.

Denial of Service

Both Consumers and Providers must consider denial-of-service attacks.

A Consumer can prevent a Provider from doing its job by withholding data. This has a high cost for the Consumer because the Provider can decide to EndJob(), and the Consumer has to submit jobs on chain.

A Provider can attempt to degrade the work being performed for the Consumer. Since the Provider has to pay to claim work and degraded work might fail verification, this attack is costly for the Provider. Additionally, the Consumer can call EndJob() and move to a new Provider. With small improvements to the intelligence of the Consumer, rewards will be more efficiently distributed to well behaved nodes. This is both a defense against denial service and a scalability feature. Providers who fail and are slashed often will rationally lose stake, and no longer be able to claim work.

Attacks and Faults

Proposals can be submitted for adjustable parameters like UnbondingPeriod, RoundLength, InflationRate, and VerificationRate. Voting by Providers according to their delegated stake can determine the adoption for protocol parameter adjustments. Effective Governance is critical to the success of the Transmute Network. As such, the next section of the whitepaper will be updated as required to support healthy network operation.

The security properties of the Transmute Network are generally determined by rational pursuit of economic self-interest. However, even unprofitable attacks can cause serious disruption to system fault and should be thoroughly understood to mitigate risk.

1 3

Useless Work

A Provider with enough stake to maintain rank can list 100% BlockRewardCut, 0% FeeShare, and a high PricePerMineral such that they could collect token rewards without contributing work. This is prevented with CompetivenessTolerance which enforces that all Providers contribute some valid work. The result is that this strategy is less profitable than staking towards an honest Provider.

Centralized Failure

Centralized services and nodes are vulnerable to censorship, surveillance and injection attacks from network adversaries. Projects such as Tor and I2P [17,18] can provide relief, but IPFS and Ethereum networks should be treated as public, meaning application level cryptography should be implemented by developers.

As aforementioned, decentralization has some desirable properties for developers and users:

Decentralization

Prior to the popularity of blockchains, a family of cryptography products existed to provide abstractions and great user experience for encryption key management, identity, integrity, auditability and payments. Blockchain and other decentralized technologies provide a platform for developing these kinds of products, that has a built in recruiting mechanism for training the workforce: tokens. In order to unlock the customer and product opportunities provided by decentralized technology, it is necessary to develop decentralized technology. For enterprises that have recently migrated to the cloud, this prospect is concerning. The Transmute Platform addresses this concern, by providing a common development environment so that applications can be moved back and forth between the centralized world and decentralized world.

Centralized solutions are completely outside of the users control, their only means of interacting with the software is through a user account. Users are not able to interface with tthe machine or their keys directly.

Hybrid solutions exist as decentralized software solutions running on centralized hardware, or they can be centralized software running on decentralized hardware. An IPFS node on AWS or a DApp with Firebase login. By combining decentralized and centralized technologies, developers can reach new users and offer them safer experiences – all while still providing the business reporting, surveillance, and censorship capabilities that many corporations rely on.

Users control their keys; thus, users are in control.

Ledgers and audit logs are immutable.

Content addressing is efficient; binaries are hashes; apps are portable.

Crypto-economic incentives are real, as are regulations.

—

—

—

—

Infura Ethereum Node Your Ethereum node on AWS EC2 Your Ethereum node on your computer.

S3 on AWS Your IPFS node on AWS EC2 An IPFS node on your computer

Lambda on AWS Your OpenFaaS node on AWS EC2 OpenFaaS node on your computer

Centralized Hybrid Decentralized

1 4

Decentralized solutions have no dependencies on any centralized services. A purely decentralized application only needs to talk to Ethereum and any number of peer-to-peer networks overlaid from Ethereum data. These applications represent the most valuable opportunity for developers seeking to deliver applications that operate on market behavior, as the ability to regulate the application behavior is equivalent to the attack cost on the decentralized technologies the application is built with. For example, a desire to force Ethereum to block payments to certain journalists. Decentralization is powered by a democratization of the cryptography used to secure information systems combined with a growing distrust of centralized platforms’ ability to provide true security to users.

Decentralized Blog

Many blogging platforms such as Wordpress rely on a web server, database and front end code to provide a rich user experience. Projects like Akasha [12] are offering Ethereum users a social network experience powered by Ethereum, IPFS, React with Redux, and Node.js. When the Transmute Platform is complete, we hope to support projects like Akasha by providing a simple developer friendly way to run and develop applications with decentralized dependencies.

Decentralized Exchange

EtherDelta [13] is a decentralized trading platform that lets you trade ether and other tokens with others. Trading platforms often have centralized web services for requesting price feeds that interact with other services on the internet and providing an application experience for normal internet users. The Transmute Platform could allow users to collaboratively host EtherDelta, but any requests to external internet services could still be censored.

Decentralized Supply Chain

Supply chain management is critical for a wide range of companies, including Apple, Amazon, Whole Foods, P&G, Pfizer, and others. Decentralized supply chain software leveraging blockchain technology is resilient to node failure, denial of service attacks, backdoor installation, and coercion or fraud because the cost to attack the integrity of the supply chain is at least as great as thecost to attack the underlying blockchain. Additionally the common cryptographic language offers parties the ability to collaborate in a trust but verify environment. The transmute platform is designed to interface with public and private clouds, providing an easy extension point for unlocking decentralized potential.

Decentralized PaaS

Services like Kubernetes on GCP [14] or Kubernetes on Microsoft Azure [15] provide a PaaS offering with some potential for portability. Many developers prefer to work with abstractions that do not tie them to a single public cloud provider; the Transmute Platform was built with this in mind. Though our initial technology offerings are focused on Ethereum, IPFS, and Functions, we plan to incorporate the newest and most valuable decentralized technologies as they come online.

Use Cases

1 5

The Transmute Protocol incentivises nodes to provide a decentralized cloud for dApp developers and consumers. Verification of the work conducted by nodes is solved by a scalable extension on top of Truebit protocol, and DPOS concepts - including fees, rewards, and slashing - are used to incentivize nodes to behave honestly when pursuing economic self interest. Providers compete to be selected for the profitable role of servicing consumers. The network parameters are chosen to ensure that it is more profitable to delegate stake to a Provider than cheat or attack the system. This results in a scalable, pay-as-you-go, decentralized cloud development and production environment, with a unique ability to deploy centralized, decentralized, or hybrid applications with minimal configuration changes.

Summary

Transmute Protocol Parameters

Appendix

Name Description Example

Infura Ethereum Node Number of active Providers 137

InflationRate The target annual inflation rate for TST 15%

RoundLength Length of round in days, where work parameters are fixed.

1 day

UnbondingPeriod The time required to wait before funds can be withdrawn after entering unbonding state.

1 month

VerificationRate The percentage of mineral access that willbe verified.

1/500

FailedVerificationSlashedAmount The percentage to slash in the case of a failedverification or threshold breach

5%

VerificationPeriod The deadline for verifying a job claim after theclaim has been submitted; also the duration a receipt must be persisted for verifiers.

6 hours

RateLockDeadline Provider rates are locked at this time prior to the next round

6 hours

MissedRewardSlashedAmount The percentage to slash in case of missing a blockreward round or threshold breach

3%

MissedVerificationSlashAmount The percentage to slash in the case a Providerfails to call verify or threshold breach

10%

CompetitivenessTolerance The percentage of work a Provider is required to do

90% with 100 Providers and100,000 mineral requests. A Provider would pass if they onlyworked on 100 minerals. Thatwould be 10% of the 1000, thatwould have been a fair share of the work for the Provider to do.

1 6

Name Description Example

SlashingPeriod The deadline for invoking a slashing after theVerificationPeriod has completed.

1 hour

FinderFee The percentage of a slash a finder will becompensated

Placeholder thresholds There are many percentages which might better be represented by thresholds, includingslashing and verification failures, using thresholds provides resilience in case ofexternal failures from Truebit or IPFS.

5%

VerificationFailureThreshold The percentage of of verifications a Providercan fail before being slashed.

1%

Transmute Protocol TransactionsTransaction Description

Bond() Bond TST stake as a Provider

Unbond() Enter unbonding state for UnbondingPeriod

Provider() Declare intention to Provide

ResignAsProvider() ResignAsProvider() Resign intention to Provide

ProvideAvailability() Declare active participation and willingness to accept work as a Provider.

Job() Job() Submit a Provider job on chain.

EndJob() End job and cease providing.

Deposit() Submit a deposit on chain to be used to pay for the work of a job.

Withdraw() Withdraw from deposit and unbonded stake

ClaimWork() End the job and claim the mineral work you can prove via a merkle root.

DistributeFees() Provider claims fees for a claim after verification

Verify() Provider provides the claims necessary for mineral which willbe verified along with merkle proofs for comparison withmerkel root from ClaimWork() including a call to Truebit.

Reward() All verification is done on chain to determine slashing or rewards. Only invokable by active Providers once per round.

InitializeRound() Called once per round to initialize the new active provider pool.

UpdateDelegatorStake() Invoked automatically during bonding and unbonding, enablesdelegator to claim fees and rewards from the previous rounds.

Placeholder governance Governance available to stakers to be further defined.

1 7

H e l l o , 0 x 8 4 e d 3 1 e 5 6 1 3 7 6 2 6 e f 9 7 5 4 7 e 8 d 5 e f 4 2 1 cD A P P S S E R V I C E S I N S I G H T S D O C U M E N TAT I O N S U P P O R T

M Y D A P P S C R E AT E D A P P

Dapps

C E N T R A L I Z E D D E C E N T R A L I Z E D

Create your DappChoose a hosting provider

S E L E C T C O N F I G S E L E C T C O N F I G S E L E C T C O N F I G

C E N T R A L I Z E D D E C E N T R A L I Z E D

Choose a Storage Provider

S E L E C T C O N F I GS E L E C T C O N F I G S E L E C T C O N F I G S E L E C T C O N F I G

C E N T R A L I Z E D D E C E N T R A L I Z E D

Choose a Computation Provider

S E L E C T C O N F I G S E L E C T C O N F I G S E L E C T C O N F I G

Decentralized Services and Oracles

Enter Search Terms Here

Finalize and Create

Dapp name

S E L E C T C O N F I G S E L E C T C O N F I G S E L E C T C O N F I G

C R E AT E

Product IllustrationsThis section contains product illustrations for the our web dashboard. This work is ongoing, and these images should not be interpreted as finalized or feature complete. The web dashboard will be available as a centralized web application hosted by Transmute Industries, and as a decentralized web dashboard for interfacing with the Transmute Platform. Some illustrations shown here will only be relevant to the centrally hosted SaaS version of the platform.

Create Your DappAs the platform evolves, we plan to support boilerplate code generation via the command line interface and the web dashboard. Users can choose the centralized or decentralized supported technologies which make the most sense for their application, and quickly get started.

1 8

References

1 9

01 Ethereum

02 l ivepeer

03 Golem

04 iExec

05 Enigma

06 ChainLink

07 Filecoin

08 Truebit

09 Tendermint

10 BitShares

11 Steem

12 Akasha

13 EtherDelta

14 Kubernetes on GCP

15 Kubernetes on

Azure

16 OpenFaaS

17 Tor