★ [ANN] 🔵 BLUE: Securing the Crypto Age | YoBit | CoinExchange | CMC

Ethereum Blue – White Paper
Released October 28th, 2017
Image
A proposal for securing cryptocurrency and Ethereum Smart Contracts Bringing Confidence to Cryptocurrency Written by Team Blue

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 token’s 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]

So to summarize, when a coin, exchange, token, or other cryptocurrency that has any sort of return guaranteed, it’s advisable to proceed with caution.

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.

However, many cryptocurrency enthusiasts are of the position that a metaphorical gold-standard in virtual currencies requires the strict limitation of total tokens available. Even in the case of currencies such as bitcoin which can continue to be mined over time, there is an eventual end to the feasibility of mining activity, and therefore a real mathematical maximum capacity for the total number of bitcoins that can eventually be created.

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.

Image
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 blockchain’s 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.

Image
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.

Image
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 SVM’s, 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 actor’s 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 project’s 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 it’s 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