EVILink

EVILink shows that a malicious miner still has a slim chance to tamper randomness provided by Chainlink's VRF solution.

• EVILink
  • Concept
    • What a Slim Chance
    • Proof of Concept
    • Rethink
    • Take Away
  • Packages
    • Contracts
    • Common Utilities
    • Chainlink Utilities
    • Applications
  • Development
    • Prerequisite
    • Prepare
    • Build Docker Image
    • Start Docker Container
  • Reference

Concept

What a Slim Chance

Chainlink VRF is an awesome solution for NEARLY tamper-proof randomness. Why say NEARLY tamper-proof? For a verifiable randomness implemented by Chainlink, it is composed by these parameters ordered by their generation time:

1. vrf_key - generated before the corresponding public key registered as VRF service
2. user_seed - provided when user interact with the contract
3. block_hash and block_number - block containing the event RandomnessRequest

The only parameter tamperable after transaction sent is the block_hash, which can be easily tuned by change the block head extra data, but miner still has no way to predict randomness if it does not have vrf_key. However, there exists these situations for randomenss to be tamperable:

1. vrf_key is leaked to miner
2. vrf_key is held by miner from the beginning
3. miner conspires with the malicious vrf_key holder

So miner can tune the block_hash to get the favorable result before mining.

Condition	Diagram
Normal
Key Leaked

Proof of Concept

Here I present the first situation of randomenss to be tamperable to hack a coin tossing game. When malicious miner steals the vrf_key, it can make owner of the contract FlipCoin.sol always win and others always lose.

Owner	Others

Rethink

So why Chainlink includes the manipulatable block information to be part of randomness? The reason is because the randomness will be fully manipulatable by vrf_key holder if it is only composed by vrf_key and user_seed (when holder is the user). The design to include block information prevents the single-point-malicious in most time.

Take Away

From Chainlink's awesome blog, they are already integrating threshold signatures with VRF to prevent single-key-leaked-failure, which is not only cost-effective and high-availability, but also is almost a tamper-proof randomness solution (in theory we still have very slim change to collect enough key shares, but extremely hard). Super looking forward to the approach.

But before the upcoming approach, we can still use current version VRF with some good practices:

1. Contract should have a mechanism (by voting or by admin) to change the VRF service in case current one is thought malicious or key leaked.
2. Contract could request multiple randomness in one transaction and combine incoming randomnesses to be final randomness for a safer approach, it will be tamper-proof when at least one secret key holder is safe and honest. However, it costs much more both time and LINK. Implementation can be found here.

Packages

Contracts

Package	Description
@evilink/contracts-chainlink	Chainlink related contracts
@evilink/contracts-faucet	Faucet contract for ether
@evilink/contracts-flipcoin	Coin tossing game using VRFConsumer

Common Utilities

Package	Description
@evilink/artifact-util	Artifact util for contract factory
@evilink/constant	Constant including contract address, genesis private key

Chainlink Utilities

Package	Description
@evilink/chainlink-client	Chainlink API client
@evilink/chainlink-orm	Chainlink ORM client
@evilink/chainlink-vrf	Chainlink VRF implementation in golang as gyp binding

Applications

Package	Description
@evilink/evilthereum	Malicious miner with VRF key hacking VRFConsumers
@evilink/playground	Frontend for interaction with hacked contracts

Development

Prerequisite

• go1.15
• yarn2

Prepare

# build chainlink vrf for gyp binding
pushd packages/chainlink-vrf/go && make && popd
yarn --immutable
yarn build

Build Docker Image

bash script/run.sh build

Start Docker Container

cp docker-compose.sample.env docker-compose.env
# after update the values in docker-compose.env
bash script/run.sh up
# wait for ipfs and graph-node ready
bash script/run.sh deploy_subgraph flipcoin

Reference

• Chainlink VRF: On-chain Verifiable Randomness
• Making NSEC5 Practical for DNSSEC