Haven’t you heard, anon? DeFi is dead. Long live DeFi. Long live Yearn.

We’ve been preparing for a bear market, which is why we have a buffer of ~$20 million. But it’s not going to last forever, and that’s why we’re taking steps to make our warchest last as long as possible.

As contributors, we have identified inefficiencies that accumulated during the bull, and are now rethinking how we work and on what. We can do more with less.

Below we outline the action plan we’re executing against during the current market downturn in order to become more resilient.

Specifically, we focus our work to:

Overhaul V2

Simpler and more automated strategies, reduce maintenance and overhead costs. Focus on Ethereum and its Layer 2s, and simplify the product offering. This will allow us to revise our fee structures and become more competitive.

Prepare V3

Continue iterating, testing, and experimenting with the new V3 design, taking it to production, and ultimately have it replace V2.

Grow B2B

Tools, documentation, tracking. Focus on automation and helping integrators onboard themselves. Offering a concierge-like experience for the largest depositors to retain their TVL.

Release tokenomics

Finalize and launch veYFI and redistribute bought back YFI as added APYs to vaults to reclaim some of our lost TVL. Monitor performance and propose evolutions to YFI’s emission model as required.

Stay on top of security.

Continue best-in-class security to provide the most attractive risk-adjusted yields in the market. Monitoring, peer reviews, audits, risk framework, testing, and simulations.

Research new growth verticals

Small, contained research efforts to explore new sources of sustainable revenue and business models for yearn.

We’re doing this with less resources, taking a back-to-basics approach with a heavy focus on our core product and services, strategies, vault operations, engineering, and security. The plan is being actioned as part of our day to day operations. If you have thoughts, ideas, or questions get in touch with us on Discord.

These are tough market times, but we’re seeing a lot of untapped opportunities and are confident we will come out stronger from this.

As always, we appreciate the support and belief in the team of yearn contributors.

Today we’ll look into MakerDAO voting process and recover the complete state of the governance contract. There are two types of voting: governance and executive. Governance voting can be seen a simple yes/no poll. Executive voting is much more interesting and it will be the subject of this article.

How voting works

Executive voting is handled like approval voting:

• Anyone can create a proposal;
• Users can vote for one or more proposals;
• A proposal with the most votes gets the superpowers and can modify the system parameters.

Proposal contract

A proposal comes in a form of smart contract. The winning proposal is given the authorization to tap into mom contract. A common pattern for these contracts is to use ds-spell, which performs a single action once.

The proposal to reduce the stability fee from 2.5% to 0.5% can be seen below. It shows which contract it calls, the call data and whether is has already been executed.

We can verify the spell using a simple script that decodes the data using interface (ABI) of the target contract:

The result would be: setFee(uint256 ray 1000000000158153903837946257)

How is this 0.5%, you may ask. To figure this out, we need to understand the units which this number is expressed in. Maker uses a few different units with various degrees of precision: wad, ray and rad.

The argument title suggests the value is in ray, a fixed point number with 27 decimals. So it expresses 1.000000000158153903837946257.

Turns out that the unit is the fee multiplier per second, so if we exponentiate it to the number of seconds in a year, we should get 1.005 or 100.5%.

1.000000000158153903837946257³¹⁵³⁶⁰⁰⁰ = 1.005

The proposal checks out! Go vote for it and come back for more fun.

Voting contract

Now let’s take a look at the voting contract, ds-chief. To vote for a proposal, one must lock MKR in this contract in return for IOU tokens. Only the locked tokens count as votes.

Users vote for sets of candidates, which are stored in a slates mapping. There are two ways to vote:

• vote(bytes32 slate) vote for an existing set of candidates.
• vote(address[] yays) vote by providing a set of candidates, which also saves them into a slate using etch(address[] yays).

The contract tallies the weights and awards the leading proposal with a hat. Having the hat means having superpowers. Now anyone can cast the spell and modify the system parameters.

The voters

With that knowledge, we can find all the proposals and voters. The plan:

1. Find all the slates by looking at Etch(bytes32 indexed slate) events.
2. Look up the proposals in the slates mapping.
3. Fetch all votes and remember the most recent ones.
4. Combine them with deposits of each voter.

First, we save unique slates from the Etch events. Then we read the values from each slate array starting with index 0 and continue until we are out of bounds.

The vote calls use non-standard events fired by ds-note. It provides a note modifier, which stores the function calls as indexed logs. There is no need to define events for each function, ds-note handles that on a lower level.

To isolate the two functions (vote slates and vote yays), we need to construct a correct log filter. If you specify a topic in a filter as a list, it works like logical OR, which is exactly what we need.

The first topic is a 4 byte function signature encoded as bytes32. The log data will have what we need to recover the votes.

The voting system is using a proxy contract, so we can’t just look up the sender in the from field of the logs. Luckily for us, ds-note stores msg.sender as the second topic.

The “slates to yays” we got earlier comes in handy for looking up candidates each user has voted for. The last step here is providing everyone with a voting weight based on their deposit.

Now we can combine everything to see the complete picture.

The full script that also tries to decode the spells can be found here.

Today was indeed a productive day, hope you learned something useful. Subscribe to crypto eli5.

According to Ethernodes, Etherum mainnet is dominated by Geth (55.7%), Parity Ethereum (31.5%), so we’ll discuss these two. All tests are done in October 2018 on a $30/mo dedicated server with the following config:

2.4 GHz CPU with 8 cores
16 GB of RAM
250 GB SSD
1 Gbit network

Geth

Geth (also known as go-ethereum) is written in golang and uses Google’s LevelDB as a storage backend. The default sync mode is called fast, it downloads all the needed data in parallel:

• Block headers (6,475,108 headers took 13 hours 25 minutes)
• Transaction receipts (same amount, finished roughly at the same time)
• State tries (syncing 227.8 million states took 1 day 10 hours)

A few hours into the sync, a message saying “Database compacting, degraded performance” starts to appear. The first one is at 4 hours 13 minutes mark and it gets worse after that. Geth ends up spending 4 hours 19 minutes (¹⁄₈ of the total time) completely halted by LevelDB compaction. After headers and receipts have finished downloaded, state sync finished without interruptions.

A few minutes after the last state entry was downloaded, the node appeared fully synced.

The final time is 1 day 10 hours. The database size is 130.9 GB.

Unfortunately, Geth’s eth_syncing command doesn’t provide enough meaningful info to calculate the remaining time. It would be great to know how many states are there to sync, but traversing the whole state trie is probably a very expensive operation.

Parity Ethereum

Parity Ethereum (formerly Parity) is written in Rust and uses Facebook’s RocksDB as a storage backend. It’s backwards compatible with LevelDB, and has a bunch of additional features.

Parity syncs in warp mode by default, which works like this:

• Pull a recent snapshot (2209 chunks took 2 hours 20 minutes)
• Sync the few remaining blocks (4651 blocks took 1 hour 33 minutes)
• Process older blocks in the background (6,500,000 blocks in 1 day 2 hours 39 minuts)

This makes the node usable after about 4 hours. You can interact with the blockchain and query the recent state and blocks that came after the snapshot with the older blocks unavailable until they are processed.

The final time is 1 day 6 hours 32 minutes. The database size is 125.6 GB.

Parity’s eth_syncing reports the total number of warp chunks as well as the total number of blocks, which allows to estimate the remaining time. It doesn’t report the status of the third step, but it can be monitored with a simple script like this:

from web3.auto import w3

for n in range(0, w3.eth.blockNumber, 10000):
    while not w3.eth.getBlock(n):
        sleep(60)
    print(n)

If you want to get a deeper understanding of these challenges, I recommend reading the TurboSync paper.

Hope you learned something useful. Subscribe to crypto eli5.

Open Protocols

The real beauty of Web 3.0 ecosystem we are building are open protocols. Anyone can tap into dharma loan protocol or 0x protocol exchange contract and get into shared liquidity pool for free. You can mix and match these too, creating completely unique products and markets.

A protocol for fungible tokens (ERC-20) is probably the most successful thus far. It secures about $13 billion across a thousand assets. This protocol is quite simple actually, it defines a transfer function which updates balances in token contract and emits a Transfer event.

But what allows to tap into it is the concept of allowance. A user can approve another account to transfer some amount on her behalf. For example, an exchange calls transferFrom user wallet when the order is filled. It’s programmed not to transfer more than the signed amount even though the allowance is set to -1 (meaning infinity).

Optimization

Like a good Unix tool, Disperse contract does a simple job and does it well, that’s why we shaved off every single bit to optimize for gas costs. A naive implementation of Disperse function might look like this:

However, it’s not an optimal solution because the aforementioned transferFrom updates allowance on each call in addition to balances. That’s an additional 5000 gas on each transfer.

A better way would be to calculate the total, transferFrom it to the contract address and then distribute the tokens using transfer function. There is no risk of funds being stuck because transactions work in “all or nothing” manner and the state will revert if anything goes wrong.

The cost also depends heavily on whether each recipient has previously had any balance. Zero balance is the worst case because storing a new state entry costs 20,000 gas as opposed to 5000 gas for changing the value.

Benchmark

Here are the benchmark results for this contract (outlined in red) compared to sending tokens to one recipient at a time (grey). One block can fit up to 218 token transfers, while Disperse transaction can fit 2.9x as much, up to 634 transfers.

Same goes for ether, one block can accommodate 380 regular transfers while Disperse can fit 2.18x more, up to 830 transfers. However, distributing ether to uninitialized accounts costs more because contracts pay 25,000 gas for calls that result in creation of new accounts as opposed to a flat 21,000 gas cost of a regular transfer.

If you are using Metamask, you are probably connected to Infura node. It limits the maximum transaction size to 32 KB. This anti-spam measure caps the amount of recipients you can specify. You can broadcast a larger transaction by connecting to to a local node like Geth or Parity Ethereum. Infura’s limit is shown with a dotted line on the charts.

Disperse

We believe this space needs more builders and less fraud. Therefore Disperse doesn’t incorporate any useless token, has no sale and takes no fees.

It’s a useful dapp that’s available day one on nine networks:

• Ethereum and its testnets Ropsten, Kovan, Rinkeby;
• POA Network and its testnet Sokol;
• xDAI Chain;
• Ethereum Classic;
• Callisto.

Go try it out on disperse.app.

Read the research paper.

Let us know what you think on Telegram.

Correction:

• Benchmark results have been revised accounting for a transaction size limit of 32 KB on Infura which is the default RPC provider on Metamask. Example transactions have been added.

Smart contracts generate logs by firing events. Here’s a transaction receipt that contains one log entry.

The log entry consists of one topic and a data field. The first topic refers to the specific event, but we don’t know which one yet. To decode the data we need to obtain ABI of the contract found in the address field.

We are interested in items with the type event. Here’s a sample event.

{
  "anonymous": false,
  "inputs": [
    {
      "indexed": false,
      "name": "from",
      "type": "address"
    },
    {
      "indexed": false,
      "name": "to",
      "type": "address"
    },
    {
      "indexed": false,
      "name": "tokenId",
      "type": "uint256"
    }
  ],
  "name": "Transfer",
  "type": "event"
}

To find out which event the topic refers to we need to compute a signature of each event and find the matching one. Signature is a keccak hash of event name and input argument types, argument names are ignored. For event Hello(uint256 worldId) the signature will be keccak('Hello(uint256)').

> keccak('Pregnant(address,uint256,uint256,uint256)')
241ea03ca20251805084d27d4440371c34a0b85ff108f6bb5611248f73818b80

> keccak('Transfer(address,address,uint256)')
ddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef

> keccak('Approval(address,address,uint256)')
8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925

> keccak('Birth(address,uint256,uint256,uint256,uint256)')
0a5311bd2a6608f08a180df2ee7c5946819a649b204b554bb8e39825b2c50ad5

> keccak('ContractUpgrade(address)')
450db8da6efbe9c22f2347f7c2021231df1fc58d3ae9a2fa75d39fa446199305

As we can see, the signature of Transfer event matches the first topic. Now we can decode the data.

> types = [i['type'] for i in e['inputs']]
['address', 'address', 'uint256']

> names = [i['name'] for i in e['inputs']]
['from', 'to', 'tokenId']

> values = eth_abi.decode_abi(types, log['data'])
('0x0035fc5208ef989c28d47e552e92b0c507d2b318',
 '0x646985c36ad7bf4f3a91283f3ea6eda2af79fac6',
 107696)

> dict(zip(names, values))
{'from': '0x0035fc5208ef989c28d47e552e92b0c507d2b318',
 'to': '0x646985c36ad7bf4f3a91283f3ea6eda2af79fac6',
 'tokenId': 107696}

We can finally read the log. The message says:

“Transfer from 0x0035… to 0x6469… of token 107696”.

Indexed fields

Each indexed field generates a new topic which is excluded from the data. This allows for efficient search but makes parsing a bit more complicated.

Let’s look at another receipt:

This one has three topic fields and a small data field. We can already tell that the first topic is Transfer(address,address,uint256) despite the different argument names in this contract.

{
  "anonymous": false,
  "inputs": [
    {
      "indexed": true,
      "name": "from",
      "type": "address"
    },
    {
      "indexed": true,
      "name": "to",
      "type": "address"
    },
    {
      "indexed": false,
      "name": "value",
      "type": "uint256"
    }
  ],
  "name": "Transfer",
  "type": "event"
}

The remaining two topics are simply indexed inputs. The only value in data is the remaining uint256.

> types = [i['type'] for i in e['inputs'] if not i['indexed']]
['uint256']

> names = [i['name'] for i in e['inputs'] if not i['indexed']]
['value']

> values = eth_abi.decode_abi(types, log['data'])
(5000000000,)

> indexed_types = [i['type'] for i in e['inputs'] if i['indexed']]
['address', 'address']

> indexed_names = [i['name'] for i in e['inputs'] if i['indexed']]
['from', 'to']

> indexed_values = [eth_abi.decode_single(t, v) for t, v in zip(indexed_types, log['topics'][1:])]
['0x00b46c2526e227482e2ebb8f4c69e4674d262e75',
 '0x54a2d42a40f51259dedd1978f6c118a0f0eff078']

> dict(chain(zip(names, values), zip(indexed_names, indexed_values)))
{'from': '0x00b46c2526e227482e2ebb8f4c69e4674d262e75',
 'to': '0x54a2d42a40f51259dedd1978f6c118a0f0eff078',
 'value': 5000000000}

Note that Ethereum always uses integers to represent numeric values, so we got the value in the minimal denomination. Move the decimal point left by decimals found in the contract, 3 in this case. The message reads:

“Transfer from 0x00b4… to 0x54a2… of 5,000,000 tokens”.

Querying

Now you are ready to do some search. You can query the blockchain using json-rpc api which is provided by full nodes like geth or Parity or a service like Infura. Bloom filters allow you to scan the entire blockchain in seconds and find logs matching the specific topic.

You can also specify search range with fromBlock and toBlock, limit the search to specific contract address and omit some of the topics with null which works like a wildcard. The full specification can be found here.

Of course, everything described here is already implemented in web3 which allows you to conveniently query the events by name and decodes logs data automatically, but if you care about performance like I do, this approach could save you a lot of time.

If you learned something new, clap and subscribe to crypto eli5.

Deep dive into Ethereum logs was originally published in codeburst on Medium, where people are continuing the conversation by highlighting and responding to this story.