Ethereum Pro White Paper

Released November 12th, 2017

Abstract
In the world of cryptocurrency, there lacks a means to provide reliable confidence in the approval
process of transactions, with the result being an increased exposure to risk for users of
cryptocurrency, especially those in the alt coin and ERC20 token world.

Our proposed design presented in this paper is intended to empower cryptocurrency users with
the same convenient confidence they have come to expect from more commonplace electronic
transactions, without the unnecessary costs, delays, and middle-men normally associated with
those methods.

The crypto world is fraught with scams, bad actors, and illegal activity as a result of its
decentralized and unregulated nature. It is the wild west of financial instruments, and we present
a way to tame it just a bit. We would like to bring peace of mind to those who invest, trade, and
pay for goods and services with cryptocurrency, and blockchain technology. This is what we are
here to share with you in this document.

Addressable Need and Problem at Large

The ERC20, ICO, and larger cryptocurrency ecosystem lacks financial transaction approval with
confidence, an expectation both consumers and merchants have come to expect as a part of
every day transaction due to the rapid adoption of electronic payment technologies over the past
30 years. Specifically, fraud checks that exist in the traditional financial ecosystem such as stolen
card detection, unusual spending activity detection, and the blacklisting of bad actors in the
economy (ultimately leading to freezing of assets) are completely missing in the world of
cryptocurrency. This has both good and bad ramifications, and we believe the bad ramifications
of this is preventing growth and adoption of crypto-currency.

There are a wide range of threats, mistakes, and deliberate scams that can materially impact
users acquiring, holding, or transferring their virtual currency. Many of these threats could be
mitigated by effectively identifying and alerting users at the time they choose to transact from their
wallets. These threats are continually evolving and often times very hard to detect, if at all, by
investors or users.

Threats in Cryptocurrency
Ponzis

Description

These are schemes that involve guaranteed profits. They generally use new investors in the
contract or tokens investment dollars (or tokens, eth, etc) as a source of profits for earlier
investors. This creates an economic system that is destined to collapse when enough investors
attempt to pull out of their positions. A real-world example was famously publicized when former
stockbroker Bernie Madoff defrauded investors for a total loss of nearly $65 billion dollars in a
Ponzi scheme [1]. Blockchain-based Ponzi schemes are likely destined to have the same
outcome, and crypto investors should avoid these types of projects.

According to an SEC investor advisory Investments tend to go up and down over time, especially
those seeking high returns. Be suspect of an investment that generates consistent returns
regardless of overall market conditions. [2]

Detection

Detecting Ponzi schemes could theoretically be possible via solidity smart contract static analysis.
By parsing the AST (Abstract Syntax Tree) of a contract, we can detect lines of code that appear
to send fixed percentage returns up through a chain of linked addresses. Not all cases of
percentage-based transfers of tokens or ETH are guaranteed to be ponzis, but it is one factor that
can contribute to an overall safety score.

With manual review of solidity smart contracts and marketing materials, the community could
report Ponzi tokens to a central repository as described later in this paper.

Bugs In Solidity Code

Description

In a document published by Consensys, A guide to smart contract security best practices [3]
there is guidance on a common list of bugs such as Reentrancy, Crossfunction Race Conditions,
Integer Overflow and Underflow, DoS with (Unexpected) revert, DoS with Block Gas Limit, and
the now corrected (via hard fork in Ethereum) Call Depth Attack.

Each one of these attacks can lead to unexpected outcomes crafted specifically by nefarious
actors communicating with the smart contract, or through accidental errors.

A high profile example of a programming error was the DAO hack, which led to a $50 million
dollar theft of virtual currencies, eventually leading up to the first Ethereum hard fork, splitting
Ethereum in to Ethereum Classic (ETC) and Ethereum (ETH) [4].

Detection

Many of these bugs cans (and are) detected via static analysis. However, this analysis and its
repercussions are not made clear to investors at the moment of transaction. Instead, they are
presented in various obscure web services that check for vulnerabilities automatically. Because
we know programming errors are already being automatically detected, we can therefore prove
that it is possible to detect at least some common bugs, and present a notice at the moment of
transfer of funds in a userfriendly way.
Second, bugs can also commonly be found by manual review, and reported by the community.

Third, by using the first two items are inputs, and a true/false label for the data, we can train
binary classifiers using industry-standard machine learning software such as Tensorflow, to infer
through generalizations of supervised learning how to predict potential bugs in smart contract
source code. At the time of this writing, the authors are not aware of a system such as this
existing in the wild. However code-level analysis via machine learning can be likened to natural
language processing, where consumers can see for themselves via language translation
software, smart assistants, and search algorithms that this type of logistic inference is well within
the realm of possibility using currently available technology. It needs only be developed and
integrated.

Token Locking

Description

In some cases, especially with ICOs that are working with certain crowd-funding provisions, it is
legally necessary to lock the transfer of tokens until a certain duration has passed, or a specific
date has occurred. There is no problem with this kind of thing as long as it is clearly stated at the
time of exchange between the would-be token investor and the token issuer. However, there are
other times where a token trading lock is set in place without the knowledge of the buyer. To
compound things, the unlocking of the token is sometimes an editable variable that can be
changed at any moment by the owner of the smart contract. This can lead to very heavy-handed
market manipulation by the smart contract owner, leading to erratic market behavior, and material
loss of value in a locked token. This centralized style of stopping all trade from happening (or
select trade) is a hallmark of a manipulative token market, and should be avoided.

Detection

Detecting token locking largely depends on a few components. The first, and simplest way to
detect token locking in an ERC20, is to examine if the AST presents a standardized set of ERC20
transfer and approval functions. If these functions are unmodified, it is extremely unlikely that a
locking mechanism is in place anywhere in the contract.

Secondly, and in addition to the above checks, it is trivial to examine the AST for date value
types. The presence of a date type alone means nothing by itself, but in combination with a
modified transfer & approve function, may mean locking is present.

If the above two detections are fired, we can assume there is at least a risk of token locking being
present, and can then proceed with a community evaluation or manual review to determine if
token locking characteristics are present, and if so to what degree these factors are influenced by
the smart contract owner.

Infinite Minting

Description
In the case of a owner-controlled smart contract, is it possible to create new tokens by simply
increasing the balance variable of an ERC20 address. For many token investors, infinite minting
gives too much centralized control over the total supply of tokens to be considered a safe
investment. Similar to how the Federal Reserve mints new dollars in the United States, infinite
minting capabilities allows for inflation. The Federal Reserve proponents would argue that this
capability allows for adjustments and corrections to the markets in the case of economic
emergencies. Whether this is true is an academic argument economists continue to have.

It is our belief that while the capability for any single entity to deliberately create inflation via the
minting of additional tokens can be used to stabilize markets, it has a negative effect on the value
of any tokens being held. Therefore, inflation and infinite minting can be viewed as a method of
systematically removing value from individuals, and redistributing it to others, and therefore may
be considered by some to not be a sound investment or adequate store of value over time. This is
made evident by the common advisory to buy gold, or other such commodities whose value is
tied directly to real-world value, rather than being controlled in value via a centralized minter.

Detection

Infinite token or coin minting is trivial to uncover by manual review, and can easily be reported.

It is also potentially trivial to uncover with fuzz testing on a private Ethereum node. Fuzz testing
involves making randomized function calls in to a smart contract, thousands of times per second
on an offline version of the Ethereum blockchain, and detecting if the total supply of coins ever
increases or decreases.

Environment and Dependencies

The system we propose involves an SDK (Software Development Kit) that could be used by
developers of wallets, private key injection bridges, exchanges, and other blockchain developers
to access a set of REST endpoints providing a centralized database of real-time calculated
scores, where the primary key used for indexed lookups via REST calls is the recipient address.
REST calls can be sent via cURL, AJAX, native http requests in mobile apps, or through the use
of an Oracle in the event of a smart contract. Because this SDK will simply wrap asynchronous
network requests, it is fairly trivial to produce, or for any open source contributor to develop a
REST wrapper, offering easy-to-use functions to retrieve scores in their native programming
language. For this reason we believe the SDK can spread to a multitude of platforms quickly, with
relative ease.

As a way to get the ball rolling, we recommend an SDK for the most common backend
programming environments, with the intent of integrating with web-based

Javascript
Python
Go
PHP
Ruby

Oracle
In the case of a smart contract, accessing an external API or web service presents a real
problem. Trust in a blockchain network relies on multiple nodes verifying transactions, and
coming to a clear consensus on the result. Introducing external dependencies threatens this
alignment among the nodes, as nodes may receive a different result. Ultimately leading to
confusion on the network.

The solution to this relies on smart contracts retrieving this external data from an oracle. An
oracle is an agent on the blockchain that listens for events that indicate a request for data. Once
an event is heard, the makes a secure request to a trusted service and pushes the resulting data
as a transaction back into the blockchain. This results in every node having the same copy of the
data bringing consensus back to the network.

A decentralized approach to testing?

In our previous explanation, we reviewed how an oracle would request data from a trusted
service. Trusting a single entity / service undermine the goals of a decentralized system, so a
decentralized approach is something to consider.

A key feature of the proposed SDK is the testing of a contract's source code using static code
analysis. This is a perfect example of a feature that could naturally be implemented in a
decentralized way. For each test within the static code analysis suite, a spec could be provided
that clearly explains what this specific test is attempting to validate. Potential test runners would
go through a vetting process to establish they have met the specification. When a request for a
test is received by the SDK, this network of test runners would all run their version of the test
spec and a consensus would need to be made on the test outcome to rule out any false
positives/negatives. This rules out the possibility for any single point of failure and would bolster
the overall effectiveness of the test suite as inconsistencies are identified and fixed.

The User Experience

An SDK could allow consumers, via wallet integrations, to automatically scan addresses before
approving the sending of cryptocurrency from their wallet.

The scan could work to identify the legitimacy, integrity and validity of the recipient address, prior
to completing the transaction. This two-factor approach will allow users to gain actionable insight
into their transaction before committing to any payment.

What Makes this Different than the blockchains existing security

mechanism?

By offering an SDK that communicates to a centralized backend, in real-time, to provide a multi-

dimensional score for your transaction and whom you are transacting with, developers can bring
together a diverse data set of usable intelligence to empower users with confidence. As opposed
to the completely decentralized blockchain, this proposal involves a centralized authority in an
advisory role.

This centralized backend works to create a comprehensive and objective risk factor, leveraging
key data points and indicators, and then providing that insight to users prior to completing a
transaction.

Determining Risk

An algorithm would bring together a complex set of data from a wide range of sources, such as
current and historical trading analysis, transactional history, community based transaction
feedback, relative currency strength, analysis of currency code and platform, development
strength, adoption and usage.

Leveraging machine learning, expert human analysis and community driven form factors will lead
to an evolving and continual improvement of identifying risk.

Machine Learning

Machine learning is a popular approach to detecting fraud, stolen cards, and the like with credit
card issuers and we believe the same approach could be taken on the blockchain. The primary
requirement for machine learning is to have an adequate amount of labeled data. For our
purposes we may use either a binary classier to indicate a simple good or bad transaction, as
well as a linear regression to address an overall risk score, such as 98% - High risk or 1% -
Low risk.

By harvesting community data, performing heuristic static code analysis, and manual review we
will collect a large labeled data set for exactly this purpose. Over time it should be possible to do
a simple linear regression on these data point. These should be normalized using sigmoid
activations due to the shallow nature of the neural network necessary for analytical analysis. A
sigmoid activation function simply causes each individual component to be normalized relative to
each risk factor.

The logistic curve of a sigmoid function. Image credit [5]

REPRESENTING DATA FOR ML

A common approach in the world of machine learning is to first change the representation of data,
so that a solution can be found in simple linear regression. We propose we would take this
approach with multiple SVMs (Support Vector Machines) that adapt each characteristic in order to
find linearly separable levels of fraud prediction.

The figure above shows the before representation of a non-linear representations of multiple
transactions on the left. Here, a linear regression would be inadequate to predict the non-linear
nature of fraud detection of a contract, address, or transaction. However by utilizing multiple
SVMs, we can represent this same data to a linear plane, and the resulting projects allows for a
simplified linear approach to predictive analysis.

Key Features

As a result of creating and leveraging an SDK, these are just a few of the features that are
possible

ADDRESS LABELING

Allows owners of an address to indicate a name and associated image with their address, in
order to transparently communicate their identity. This is most relevant in the case of an ICO from
a new company, or an exchange.

VALIDATING KNOWN ADDRESSES

By clearly identifying known parties at the moment of transactions, and presenting it in the wallet
interface, users can confirm the recipient is who they believe they are.

MULTI-DIMENSIONAL SCORING OF ADDRESSES AND SMART CONTRACTS

A risk factor aggregating a weight measurement of the common threats is delivered from the
centralized API, allowing a wallet to indicate unsafe transactions.

ROBUST BLACKLIST

A blacklist of known bad actors addresses could be stored on the centralized server. These
addresses can be updated based on the current score of any transaction occurring on an
address, and provides a quick one-shot check with a binary result of blacklisted or not addresses

FLAGGING

After a transaction has taken place and has entered the public ledger, a user could be presented
an interface to flag a single transaction as problematic. When a significant number of flags are
presented on a single recipient or sending address, the scoring system could increase the
associate risk score exponentially with regards to time, as a way to quickly stop new and
developing types of problems.

Project Risks
This is a non-exhaustive list of risk factors to this projects development. We acknowledge these
risks are present, and that there may be new and developing risks we have not yet considered.

Insufficient funding for development

Because of the application of securities laws to the funding of these sorts of projects is uncertain
and still developing, it is not clear whether and how such a project would be funded, whether
through cryptocurrency tokens or any other funding vehicles. A possible alternative path is that
this document can serve as an initial problem statement and overarching design for an open
source initiative that could be developed publicly by the community, which may or may not
include the authors of the paper.

Integration failures

It is possible that with certain existing smart contracts and immutable software deployed on the
Ethereum blockchain, it will be impossible to integrate our SDK. This is a developing area that
needs more research in to each integration point. Due to immutability of some of these types of
software, future upgrades such as integrations of this proposed system could prove impossible.

While we do not believe these risks will lead to a failure for this type of project development, it is
important to recognize and approach risks with mitigating efforts. We feel its important to share
these risks to help the community understand how and why a project such as this one could fail.
That being said, we remain optimistic.

Result
By providing users with actionable insight prior to transaction completion users can assess and
analyze their potential exposure to risk. The immediate benefit for this is recognized by the user,
but the long-term benefit for the cryptocurrency ecosystem at large is increased consumer
confidence and in turn, increased adoption. With increased adoption of cryptocurrency it is
possible to leverage these tools to offer lower rates on payments and transfers, reduce the delays
in traditional banking payments and transfers, and ultimately give power of the monetary system
back to the people who use it every day. The every day consumer grows disempowered in the
face of larger and more complex financial instruments on public markets, and we hope this
proposed design for a safer, better system will one day revolutionize how we all use money

Citations:
[1] https://en.wikipedia.org/wiki/Bernard_Madoff
[2] https://www.sec.gov/investor/alerts/ia_virtualcurrencies.pdf
[3] https://consensys.github.io/smart-contract-best-practices/
[4] https://www.wired.com/2016/06/50-million-hack-just-showed-dao-human/
[5] https://en.wikipedia.org/wiki/Sigmoid_function