Hello, I have a few questions about this bounty program #7.
I think that the snapshot fork mentioned here saves the current gno state to the cosmos hub, and provides useful functions for the saved state.

1. Are my thoughts above correct?
2. Is the implementation to create a new binary like logjack or gnokey?
3. Can I get a review of the process that I am developing correctly? (before pr)
4. If the purpose of this bounty is to create a new binary, can I have a specification that specifies the functions?

Thank you!

Trying to clarify my understanding of bounty 4 with what I read from the current Gno repo, is the end goal to be able to replace the current golang parser (adapted in go2gno.go) with this new PEG implementation?

If so, would the following overall plan look reasonable?

• Step 1: have a minimalist implementation of a PEG parser in the Gno repo, this implementation doesn't have to be feature complete, mostly to get used to the coding style of the project and have something that can be moved in the right direction,

• Step 2: start implementing the Gno syntax with small Gno code examples with the PEG parser (likely improve the way the initial PEG parser works in the process), have a sort of tool/small process to compare the produced AST with the one from the current go parser,

• Step 3: iterate until we end up at the stage where we have a near-complete support of Gno (I guess when all examples from files/test have a proper AST),

• Step 4: rework go2gno to use the Gno parser using PEG (or alternatively, have a period during which we can switch between the two implementations until we get enough confidence the PEG approach yields correct results),

Some open questions:

• Are there other potential use-cases of this PEG parser in the current codebase?
• Would it make sense to eventually have this parser written in Gno itself?

I'm unsure at this stage how far I will go; I think it's important to do this incrementally, in small steps going in the right direction, so that it's useful in case other folks want to be involved. I have some experience writing BNF parsers and rules to handle ASTs for C in the past, not sure it will help here but I think I kind-of see where most of the time will be spent.

If that sounds reasonable, I'll try to come up with a clear plan for Step 1, after playing a bit more with the current codebase.

Problems to solve, Observation and Proposals

Part 1

TL;DR, I think we want to start with a pure current snapshot of the account state, and apply any changes post-facto.

part 1: given a block height (the latest blockheight that you know), export the current account state. I believe there is already some feature written to export state (and side note, it probably doesn't use RPC)--used to generate the genesis.json from cosmoshub-3. Test it out at a recent block height. Check it against production data; for example, does it show the amount of tokens held in IBC channels to osmosis? Upload the snapshot to S3 or some other file storage provider.

Observation: Verified.

Proposal:

gaiad export --height will export state in json. It can be used as a genesis state to bootstrap a node.
I found an exported genesis state snapshot for Vega upgrade testnet.

https://github.com/cosmos/vega-test/blob/66e7ccf559998d48a5bd230a3e6146bed856a83b/public-testnet/README.md#genesis-file

https://github.com/cosmos/vega-test/blob/66e7ccf559998d48a5bd230a3e6146bed856a83b/exported_unmodified_genesis.json.gz

    curl https://github.com/cosmos/vega-test/blob/66e7ccf559998d48a5bd230a3e6146bed856a83b/exported_unmodified_genesis.json.gz
    unzip ./exported_unmodified_genesis.json.gz

"genesis_time", 2019-12-11T16:11:34Z
"initial_height", 7,368,387

It was after the Delta (Gravity DEX) 13/07/21 6,910,000 cosmoshub-4 v0.34.x

Example to find balance on IBC

• find all accounts with ibc balances

    jq  '.app_state.bank.balances |select(.[].coins[].denom != "uatom")' exported_unmodified_genesis.json
  

• find accounts holding OSMO tokens

   jq  '.app_state.bank.balances[] |select(.coins[].denom == "ibc/14F9BC3E44B8A9C1BE1FB08980FAB87034C9905EF17CF2F5008FC085218811CC")' exported_unmodified_genesis.json
  

The token name and denom mapping can be found here token hub

To program fancy logic, we can use gojq
https://github.com/itchyny/gojq

Part 2

part 2: given an account A1 at a given block height in the past T1, and current block time T2, create a list of where all the account tokens are now, as a list of {Account;Coins} tuples. So if there were no transactions signed by A1 between T1 and T2, (and no unbondings before T1), the result would be simply [{A1;C1}] where C1 are the coins held by A1 at time T1. Implementation of this feature would start with SendTx, and then become staking aware. I don't know how best to do that off the top of my head. This also probably shouldn't use RPC but instead use go functions to iterate over blocks to avoid RPC overhead. That said, I might be wrong... if the RPC can handle say a month's worth of cosmoshub-4 blocks through localhost RPC in an hour, then it's fine. This might be feasible with unix pipes, or websockets.

Observation:
we can get current snapshot balances of all accounts from the exported state.

jq  '.app_state.bank.balances |select(.[].coins | length>0)' exported_unmodified_genesis.json

OR an account's balances.

   jq  '.app_state.bank.balances[] |select(.address=="cosmos1z4x4dyylwym26gnsjw29hqjhkwrw6vv2p6t58k")' exported_unmodified_genesis.json

The exported state does not contain user transactions during a period of time
Same for the delegation, it has the current delegation state of each account without the delegation records.

   jq  '.app_state.staking.delegations'  exported_unmodified_genesis.json > delegations.json

There are 171,027 accounts with balances

There are 144,197 records in the delegations

Because delegated tokens are not part of the account balance, we will need to merge these two together to calculate how many tokens each account owns.

Proposal:

We have two options

[ A ] write a program that just merges the two files in on Json that include delegation share as the additional coin in app_state.bank.balances.coins[]

Since the dataset is not huge, we merge it in memory. We can sort delegations array by delegations.delegator_address and balances array by address first. We loop through both arrays and put the result in a merged array.

The time complexity is O(N log N) for quicksort, as the address is quite random, and O(N) for merging
The space complexity is O(log N) for quicksort and O(1) for merging

PROS: simple

CONS: not flexible. we have to modify the code and get additional insights into the data set.

RESULTS: Less than 3 seconds

Joined and Merged 300,587 Accounts and 144,197 Delegations and tallied staking shares for less than 3s.

real 0m2.437s
user 0m2.085s
sys 0m0.600s

Will publish the source code soon

[ B ] dump it to two tables in postgreSQL and write the go program to query the database.

Once we dump data in postgreSQL as balances_table and delegation_table. we joined two tables, and add atoms amount and shares amount to get the total atoms that each account owns.

PROS: a lot more flexible to run SQL against the data once it is imported into the database, especially when we want to retrieve other insights from the same dataset.

CONS: complicated to set up at the beginning.

For this part of the requirement, it is the same as getting the current balance of each account.

So if there were no transactions signed by A1 between T1 and T2, (and no unbondings before T1), the result would be simply [{A1;C1}] where C1 are the coins held by A1 at time T1.

For this part of the requirement, it needs to calculate how many coins are added or removed from the account. Since the exported state file does not contains individual transactions. We can loop through send, delegation, and unbound messages from the state.db to a postgreSQL database and then query it.

given an account A1 at a given block height in the past T1, and current block time T2, create a list of where all the account tokens are now, as a list of {Account;Coins} tuples.

part 3

part 3: given a proposal, find all accounts that voted for/against/abstain, but also accounting for overrides by time (changing votes) and by delegation (overriding the validator's vote by a delegator).

Observations:
Votes from each account are not exported. Proposals only contain tallied results in the exported state file

jq  '.app_state.gov.votes' exported_unmodified_genesis.json
[]

Proposal:

We can loop through vote messages from state.db to a postgreSQL database and then query it.

• I collect data by iterating through blocks of each chain, then decode the data to extract all the votes of gov module

I've copied down the Hub1 daemon / cli / database from the ICF archives @sunnya97 shared on the Ion telegram.

My script calling the cli to get vote & deposit data is here.

I'm currently running the script for the full Ions.json but here is a sample using the first 10 or so rows from the json plus the top few Ion drop recipient addresses. This is showing a correlation of early voting, contrary to my borked script against the figment.io endpoint.

I look to add the other two hubs, but due to disk space going to have to do them one at a time. I'll be adding to my repo, which started as a script against the Osmosis daemon to find "unclaimed" ions.

We open this issue to share the development status of Adena, a native wallet for Gnoland.

Background

• As a standalone L1 smart contract platform, Gnoland needs a user-friendly wallet for mass adoption (ex: Phantom for Solana, TerraStation for Terra).
• UI/UX of the existing interchain wallets are optimized for IBC transfers between appchains and staking, not for permissionless smart contracts.
• We feel the need for an extension wallet at this time around for the Gnoland website, which serves as the town square of the project, to improve the usability of /r/ contracts and user experience.

Current Status

• Available on Chrome: (https://chrome.google.com/webstore/detail/adena/oefglhbffgfkcpboeackfgdagmlnihnh)
  *The current downloadable version might be not working or slow due to the recent policy change by the Chrome app store. We modified and submitted it for review, which we are expecting soon to be updated.
• Website: https://adena.app/
• User Guide Docs: https://docs.adena.app/user-guide/
• Blog: https://medium.com/@adena.app/4a5d412fe820, https://medium.com/@onbloc/your-gateway-to-gnoland-f12d8ff757bf
• Available functions
  - Create & restore a Gnoland wallet with a seed phrase
  - Send & receive $GNOTs
  - Check the history of transactions (bank)
  - Run the /r/ contracts such as /r/boards and /r/users
• Backend endpoints
  - Account / Balance information / Contract broadcasting -> To staging.gno.land:36657
  - Tx data (Transaction history) -> To api.adena.app (for api testing only)
  - The Tx data is from an elastic search of an external server built by us, block- synced with Gnoland’s primitive chain gno.land. (since the :36657/block endpoint doesn’t return tx_hash at the moment, we had to build this to temporarily provide the Tx data altogether for Adena).
  - But, we don’t support the Tx data for staging.gno.land because it gets updated/trashed very often with master.
  - For the Tx data of gno.land (test1), we have successfully tested and it’s working. You can search a Tx by address, /r/contracts(CreateBoard, CreatePost, CreateReply, bank.MsgSend and etc), and block number. you can try here: https://api.adena.app/docs#/

Goals & Plans

• Get rid of external dependency for the Tx endpoint. There are two ways;
  - Use the current external server for now until the implementation of a Tx indexer to search txs
  - Get rid of this external server, and not support the Tx history for now
• Integrate Adena to staging.gno.land, test2.gno.land to increase the usability of /r/contracts and improve user experience.
  - Work on the UI of testnets - Add buttons that make Adena usable such as “Connect Wallet”, and “Execute”.
  - JS development - Open Adena extension when the button of “Connect Wallet” or “Execute” is clicked / Data transfer to Adena when a contract is signed
  - Contract integration - Support more /r/ contracts (/r/profile, governance-related contracts, etc.)
• Functions to be added as we go through the development process for Gnoland
  - Network Switch between the testnets
  - GRC-20 Management
  - GRC-721 (NFT) Management
  - $GNOT Staking
  - Governance
• Build a Web Wallet focused on Staking / Governance
  - We plan to create a web wallet, similar to a dashboard for Keplr, where users can manage their delegations and engage in governance proposals with a quality UI/UX.
• Work on Adena API & technical documentation for dapp integration (https://docs.adena.app/integrations/)

Support needed

• Enable CORS in the gnoland website server (We’re using a CORS proxy for development for now)
  - test1.gno.land (running, need CORS enabled)
  - test2.gno.land (not yet running, need CORS enabled)
  - staging.gno.land (running, enabled CORS confirmed)
• Return tx_hash at ‘:36657/block” endpoint
• UI/UX feedback for Adena

Hi! I have started working on this.

I have experience with parsing expressions from having built a symbolic math package for Julia: https://github.com/jhlq/Equations.jl

There isn't a test file for node.coffee, can someone suggest some essential tests for this component?

I’ve submitted a PR on the main repo -> gnolang/gno#119, it contains the plan and an example

Hi! I would like to claim bounty #4.
Here is my work: https://github.com/grepsuzette/joeson

port of joeson (from coffeescript/js to golang)
as literal as possible

Verbatim of the bounty (https://github.com/gnolang/bounties)
"4. Port JOESON to Go"

• github.com/jaekwon/joescript
• The intent is to create an independent left-recursive PEG parser for Gno.
• Optional: port Joescript or Javascript.
• 1000 ATOMs from @jaekwon
• More GNOTs than from #3.

Hope to collaborate more but I spend so much time on this I need to publish now.
Indicate me where to communicate if you want.

Plan

I've started working on a tool that will:

• connects to a running Gaia's RPC server
• iterates over the range of a specified block
• apply filters/rules that compute events
• a binary that allows calling the library with some filters directly configurable using flags (more a demo than really useful)
• use filters to compute a score and other metadata per account
• bundled with common filters/rules as templates/helpers
• display/export the data in a usable way (csv, genesis, ...)
• tested (not sure yet how it can be done in a nice way)
• well structured to be easily readable/extendable/reusable library
• comments, code examples, CI/CD

Current Status

• Exploration mode (all-in-one file)
• What it does "well" -> processing blocks, txs, events with Go
• What is not yet implemented -> score computing; codebase structure enhancements

Repo: https://github.com/moul/cosmos-snapshot

$> go run -v . -h
Usage of cosmos-snapshot:
  -debug
        verbose output
  -max-height int
        last block to process (default 5797010)
  -min-height int
        first block to process (default 5200791)
  -rpc-addr string
        Cosmos RPC Address (default "http://localhost:26657")

go run -v . --min-height=5200800 --max-height=5200900 --debug

go run -v . --min-height=5200800 --max-height=5200900 (without --debug, you just get a progress bar)

Questions

• @jaekwon Do you think I'm on the right track and can continue, or am I completely off track?
• some filters in the brief are not clear, I'll need some help to complete my list of filters when the project will be mostly finished

Update: see my comment below for goals and updates.

we start from 24 standard words and use something very simple that only requires sha256 to generate more 256bit values: the first one is used for standard kdf & hd derivation for secp keys. The second one for alt sha256-only-kdf for ed25519 keys.
we need a sha256-only alternative to hd derivation (or possibly something like aes could work too), at the top top level, followed by some-kdf-for-privkey. Basically I would use standard hd generation but I’m trying to only trust sha256 for important stuff, not sha512.
we should first start with a goal document, then a proposed plan document, get it reviewed, before implementation.

I've manually researched about 40 address on Mintscan (including the biggest receivers of the airdrop)

I found a match on

• Staking to Sikka at the snapshot gives at least 1 ION
• NOT ANY LONGER VALID-period of staking to Sikka (people that staked more then 1 year to Sikka get 2 ION-
• The amount of ION you get from staking to Sikka, is depending on the amount of Cosmos hubs a wallet staked. There are 3 hubs (cosmos 1, cosmos 2, cosmos 3). It doesn't matter is someone staked and stopped before the end of the hub.
• Governance vote, for every proposal that a wallet voted on, an extra Ion was received
• Some votes (like voting Yes on prop 14) didn't get an Ion. This could be because that upgrade from Cosmos 2 to 3 was declined, but the reason is unsure
• Being a validator didn't get any extra Ion
• Depositing for a proposal doesn't give extra ion
• Creating a proposal doesn't give extra Ion
• Staking to another validator then Sikka doesn't get Ion

Hello, Sam Wang said to correspond on this github page. Was looking for clarity on what exact contracts you are looking for a retrospective on / or if you are looking for someone to audit their contracts? I work at Moultrie Audits so this seems within our wheel house.

The 1000 osmo bounty is straightforward.
The 5000 osmo distribution needs a summary with amounts and osmo addresses,
and justification with links to all work.
The person who puts together such a document ought to be paid too.
I'll add 500 osmo in addition for anyone who proposes the winning summary of distributions.

bounty distributions should pay out some to notable contributions, but most of the bounty must go to those who completed the objectives; and moreso for extra work that makes the work/data/code usable for more use-cases. Figuring out the original hidden distribution of ION accounts is outside the scope of the bounty, but should be accounted for, but not at the expense of work/data/code generalization.

The ulterior point is to create a streamlined pipeline for bounty rewarding.
We can design processes outside of the blockchain, and code them in later.

• This repository summarizes the Interchain Foundation's approach to delegating its ATOMs.
  https://github.com/interchainio/delegation

• ICF funding reports 2018-2019
  https://github.com/interchainio/funding/tree/master/projects

• ICF Delegations till 4/2020
  https://github.com/interchainio/delegation/tree/master/delegations

• Original Cosmosplan by Cosmos whitepaper
  https://github.com/cosmos/cosmos/blob/master/PLAN.md

• https://interchain.io/funding/

scraped data and scripts of cosmos-hub 1-4 gov module

I made another version of ed25519 implementation here in this repo: https://github.com/nghuyenthevinh2000/bounty5

https://archive.interchain.io/

Extra data to support the manual research and proving the relation between staking at Sikka and voting

ION Airdrop.xlsx

Electric capital has identified and updated here data about all the active crypto ecosystems:

https://github.com/electric-capital/crypto-ecosystems/tree/master/data/ecosystems

what I'll do:

• score accounts based on gov votes, delegations and other factors ( like @jaekwon said in his tweet )
• try to identify whales and nuke them ?
• track atoms from tainted accounts ( like @jaekwon said in his tweet ), tainted account is like account which score below some point threshold

this should be a simple loop through gaia4's data with some custom logic

I made some modification in gnolang to implement ed25519 key. Details in this repo
https://github.com/romelukaku/Bounty5

Cosmos SDK Governance Concepts

• Option set

The option set of a proposal refers to the set of choices a participant can choose from when casting its vote.

The initial option set includes the following options:

Yes
No
NoWithVeto
Abstain

*NoWithVeto counts as No but also adds a Veto vote. Abstain option allows voters to signal that they do not intend to vote in favor or against the proposal but accept the result of the vote.

• Quorum
  Quorum is defined as the minimum percentage of voting power that needs to be casted on a proposal for the result to be valid.

• Threshold
  Threshold is defined as the minimum proportion of Yes votes (excluding Abstain votes) for the proposal to be accepted.

Initially, the threshold is set at 50% of Yes votes, excluding Abstain votes. A possibility to veto exists if more than 1/3rd of all votes are NoWithVeto votes. Note, both of these values are derived from the TallyParams on-chain parameter, which is modifiable by governance. This means that proposals are accepted iff:

There exist bonded tokens.
Quorum has been achieved.
The proportion of Abstain votes is inferior to 1/1.
The proportion of NoWithVeto votes is inferior to 1/3, including Abstain votes.
The proportion of Yes votes, excluding Abstain votes, at the end of the voting period is superior to 1/2.

• Inheritance
  If a delegator does not vote, it will inherit its validator vote.

If the delegator votes before its validator, it will not inherit from the validator's vote.
If the delegator votes after its validator, it will override its validator vote with its own. If the proposal is urgent, it is possible that the vote will close before delegators have a chance to react and override their validator's vote. This is not a problem, as proposals require more than 2/3rd of the total voting power to pass before the end of the voting period. Because as little as 1/3 + 1 validation power could collude to censor transactions, non-collusion is already assumed for ranges exceeding this threshold.

• Validator’s punishment for non-voting
  At present, validators are not punished for failing to vote.

Source: https://docs.cosmos.network/master/modules/gov/01_concepts.html#vote

An air-gapped computer is often heralded as an impervious defense to an online attack, but is that really true? Is there some way that a hacker from outside can infiltrate an air-gapped network? All cold wallets need some means of connecting to the network to execute transactions or download operating system or wallet software. With air-gapped computers, data transmission usually happens by USB.

Possible scenarios:

1. A virus infiltrates the air-gapped computer, most commonly through infected USB.

2. The virus takes control and sends instructions to a specific component of the computer

3. The virus leverages its control over the component to exfiltrate (export) the private keys

4. Side channel attacks

Not common but possible:

-Virus takes control of the computer fan to exfiltrate information through sound

-Virus manipulates hard disk drive noise to exfiltrate information

-Virus causes the air-gapped computer to output radio signals generated by the computer’s electromagnetism

-And in the most alarming example, a virus was even able to use ultrasonic waves to output the private key information stored on an air-gapped computers and air-gapped Raspberry Pis

The dangers to air-gapped computers don’t stop there for users of third-party operating system or wallet software. In an example of how even software downloaded from trusted official pages can carry its own risk, hackers in 2016 replaced the official Linux Mint download icon with their own backdoor program. Just as this malware link affected everyone who clicked where it was inserted on the Linux Mint download page, a virus can infiltrate an air-gapped computer in the form of “trusted” software.

Android Devices as Cold Wallets:

Above pointed out the various reasons why offline computers cannot be considered truly air-gapped. But what about smartphones, which have no fans or mechanical hard drives?

Let’s first take a look at Android phones. Android phones rely on TrustZone for security (Let’s take it for granted that private keys are actually being stored in TrustZone, although there have been known to be incidents where unscrupulous vendors weren’t doing so). Demonstrations of leaking private keys through side-channel attacks show that TrustZone can be quite vulnerable. This means that if an attacker gains physical access to an air-gapped Android, they can steal its private keys through complex but practically achievable methods. Android chip manufacturers can release patches once zero-day attacks are discovered, but Android device makers then need to pass them on to users, which they sometimes don’t agree to do.

iPhones as Cold Wallets:

iPhones use something called the Secure Enclave, which can be understood as a Secure Element embedded in the main processor. As the likeness in name suggests, Apple’s Secure Enclave pioneered the use of Secure Elements in smartphones. The Secure Enclave is capable of performing pretty much every function of a Secure Element including true random number generation (TRGN) and even shares most of its physical properties

Despite what the Secure Enclave is capable of, it’s completely useless for cryptocurrencies because Apple has total custodianship of the private keys and does not open their use up to any other party. Not only is Secure Enclave based on secp256r1 elliptic curve encryption while Bitcoin uses secp256k1, but even if Secure Enclave supported secp256k1, Apple doesn’t provide an API for extracting private keys or the recovery seed

Because you cannot use the Secure Enclave for anything other than Apple ecosystem functions, you need a third-party app to use an iPhone as a cold wallet. The fact that transaction signing and private key storage then have to happen on the iOS level and not within the Secure Element represents an incomparable difference in terms of security. Private keys stored on the iOS level are an easier target for the side-channel attacks described above as possible on TrustZone. Furthermore, as all random number generation on wallet apps is algorithm-based, you’ll end up with a pseudorandom rather than true random number for your recovery seed

While an iPhone has a smaller attack surface than a computer and does not use USB data transmissions, it isn’t much safer because Secure Enclave can’t perform transaction signing and private key storage in a secure environment or TRGN in a way that is recoverable. Even if Apple were to add support for secp256k1, you would not be able to backup your wallet if anything happened to the iPhone. Neither will Apple’s release of CryptoKit signify a change for cold storage.

Sum-up:
Hardware wallets are minimalistic devices with drastically reduced attack surfaces. While air-gapped smartphones are somewhat safer than air-gapped computers, don’t be lulled into a false sense of security by the tradition of using either. If you’re truly interested in securing your assets, you should only be looking at hardware wallets with a Secure Element.