0xekez

Here I describe a CosmWasm key value store that allows incrementing and decrementing values at a times in the future. For example, using this map a staking contract may increment claimable balances at time $now + unbondingDuration$ during an unstake transaction. I analyze its runtime and show that the complexity of a load is $O(1)$ and the complexity of a store scales with the number of times the unbonding duration has changed.

---

Let $snapshots$ be a map where $snapshots[key, time]$ holds the value of a key at a given time. If a $(key, time)$ pair does not have a value, its value is the most recently stored value for that key.

$$ times(k) = \{t \mid \forall (k', t) \in snapshots,k=k'\} $$

0xekez

here i describe a design of a gas-efficent, ranked-choice voting system.

the problem

the most common form of ranked choice voting, instant run off, works like this:

1. voters submit a list of candidates sorted by their preference.
2. if there is an option with the majority of first-preference votes, that option is the winner.
3. otherwise, remove the option with the fewest first-preference votes from all preference lists and repeat.

prestwich

How to break up a monorepo using git subtree:

0. Set up some basic stuff:
   • These should be independent, not nested

$ NEW_REPO_PATH=
$ OLD_REPO_PATH=

blockpane

# add this to your .bashrc (and edit the list of chains to your liking
# it will enable tab completion on the command line for each :)

while read autocomplete; do
	hash $autocomplete 2>/dev/null && . <($autocomplete completion)
done << EOF
junod
kava
osmosisd
secretcli

faddat

go mod edit -replace github.com/tendermint/tm-db=github.com/baabeetaa/tm-db@pebble
go mod tidy 
go mod edit -replace github.com/tendermint/tendermint=github.com/notional-labs/mev-tendermint@0db69e64a2e87bb29b4417780da30630df97cadd
go mod tidy
go install -ldflags '-w -s -X github.com/cosmos/cosmos-sdk/types.DBBackend=pebbledb -X github.com/tendermint/tm-db.ForceSync=1' -tags pebbledb ./...

faddat

#you'd run these commands in the folder with the chain's source code.  It will replace tm-db with a tricked out version that Notional, Terra, and others contributed to over time.
# Specifically, I am looking to gather evidence around this and move forward with it. 
go mod edit -replace github.com/tendermint/tm-db=github.com/notional-labs/tm-db@a6ddc62
go install./...

joeabbey

Introduction

Osmosis is an automated market maker for interchain assets. Over the past 7 months, the adoption has continued to accelerate with nearly $1.5B in TVL as of the time of writing. Additionally, the AMM supports 33 unique assets and continues to add new assets as new chains join IBC.

Osmosis is unique from other Cosmos Chains with the implementation of an epochs module. The epochs module hooks the incentives and mint keepers to distribute various rewards once a day. With the growth of the network, increase in incentivized pools, the time to compute the epoch block and produce a NewHeight has increased to roughly 20 minutes.

New users are coming to Osmosis everyday and stay for its ease-of-use, access to many new assets, and incredible speed. The epoch block takes new users by surprise, and can be a negative experience. With more AMMs arriving in the IBC ecosystem, giving us

0xdef1

import { LCDClient } from '@terra-money/terra.js';

const terra = new LCDClient({
  URL: 'https://lcd.terra.dev',
  chainID: 'columbus-5',
});

const pools = [
    {
        name: 'bLUNA-LUNA',

blockpane

LVM Setup on DO for striped block devices:

This example is specifically for my Osmosis seed node, that I run in the cloud, all my other nodes are on hardware, and I use a very different setup on those.

These instructions should work on just about any cloud provider, by striping block devices it's possible to get much higher IOPS and throughput. On Omosis in particular this is important. It doesn't cost any more to use striped volumes, so for example 3 40GB volumes cost the same as a single 120GB, but give (almost) 3x the performance.

After provisioning new block devices (do not format automatically) in the DO console and attaching them, ssh into the droplet and as root follow the directions below. I try to shoot for < 50% usage, so right now with about 120GiB needed, three 90GB volumes will do nicely.

_Note that extending the volume group in the future will require adding exactly the same number and size of volumes. Alternatively you can just use the same procedure here to move the files into a new vol

vncsna

set -e, -u, -o, -x pipefail

The set lines

• These lines deliberately cause your script to fail. Wait, what? Believe me, this is a good thing.
• With these settings, certain common errors will cause the script to immediately fail, explicitly and loudly. Otherwise, you can get hidden bugs that are discovered only when they blow up in production.

• set -euxo pipefail is short for:

set -e
set -u