# 1000 Validators Effort (Aka Validatorship Invites/Airdrop) Polkadot should scale linearly in the number of validators, well once parachains work, including direct UDP connections between validators. We impove security if we diversify our validator operator pool too. We therfore want W3F to invite fresh-but-good validator operators into the communite and nominate their nodes, but this risks W3F being slashed. It's impossible to mitigate slashing risk while staking unknown people (see slashing section below). We could vet new validators whom we stake, and we should do some of this, but vetting becomes time intensive. Instead we should vet validator operators using their past public activity on peer-to-peer networks, which for diversity should ideally lie not be crypto-currency networks. There are three enormous peer-to-peer networks that fit this critertia, Tor, I2P, and Bittorrent. We'd presuably start new operators on a test network, or Kusama, and then graduate them to Kusama and Polkadot. ## Tor Tor provides a near perfect resource here. Tor actively avoids node hosting infrastructure homogenaity, ala EC2, etc., so Tor operators bring hosting diversity and thus security. Tor spends considerable effort teaching operators about basic operational security for peer-to-peer nodes. Tor even educates operators about interactions with law enforcement. Also, Tor operators can be solicited via Tor's mailing lists. Tor publishes a "concensus" of all Tor relays, including their long-term keys and other details, which permits unbiased path selection by Tor clients and other features. Tor even keeps historical records for their concensus. In other words, Tor itself acts as a strong character witness becasue a long-term Tor node represents a serious sustained altruistic act by the operator. We should favor nodes with good flags set, like exit, guard, etc. and reject nodes with bad flags set. If desired, we can champion geograpic diversity by favoring nodes outside Europe and the U.S. ala https://tormap.void.gr/ Is this easy? Yes it's fairly: We first download historical records from metrics.torproject.org and/or archive.torproject.org likely via rsync://metrics.torproject.org We then write a parsing script that takes a list of applicants by ed25519 master public key, extracts their data from Tor's history, and prioritizes them based upon our criteria. Any tor relay has a data directory that contains either an ed25519_master_id_secret_key, or maybe ed25519_master_id_secret_key_encrypted, or else both ed25519_signing_secret_key (?) and ed25519_signing_cert, and perhaps places the master keys elsewhere. We need tool that converts either from a substrate ed25519 controller secret key to tor's ed25519_signing_secret_key, or else that converts from tor's ed25519_signing_secret_key to a substrate ed25519 controller secret key. After we write this tool, then a script to certify it using their tor master key looks vaguely like: ``` TorDD=/var/lib/tor # Put your data directory here # We need tor to certify our new key using its master id key. # As https://trac.torproject.org/projects/tor/ticket/17127 was not # resolved, we do this by creating an ephemeral tor data directory # in which we can create a new signing key for tor to certify. # See https://trac.torproject.org/projects/tor/wiki/doc/TorRelaySecurity/OfflineKeys # if you need to make this work with offline tor master id keys. WORK=/tmp/TorEphDD mkdir $WORK cd $WORK F1="$TorDD/ed25519_master_id_secret_key" F2="$TorDD/ed25519_master_id_secret_key_encrypted" if [ -f "$1" ]; then ln -s "$F2" elif [ -f "$1" ]; then ln -s "$F2" else echo "$FILE does not exist." fi # TODO: Input a substrate ed25519 controller secret key passphrase # and construct the file ed25519_signing_secret_key expected by tor. missing_code # We need --SigningKeyLifetime '0 days' because our fresh substrate # controller key always gets an expired certificate for tor itself. # We expect this reads the existing ed25519_signing_secret_key and # creates a new updated ed25519_signing_cert. tor --keygen --DataDirectory . --SigningKeyLifetime '0 days' # Now submit the new ed25519_signing_cert as an applicaiton for nomination curl -X POST --header "Content-Type:text/xml;charset=UTF-8" --data-binary @ed25519_signing_cert https://invitetor.web3.foundation # TODO: If ed25519_signing_secret_key was not created above, then # actually the above tor command creaated one, so we could convert # it into a format usable by substrate. rm ed25519_signing_secret_key ``` If desired, we could actually convert from sr25519 keys here since this code only operates ephemerally and need not be portable across ristretto implementation, but doing so would anger the daleks. We should ask if there any way to embed additional data in this certificate, and figure out if we'd want to do so. At our end, applicaitons should consist of a certificate on a signing key by a mater key. We evaluate the application based upon the master keys' record, but should reject signing keys taht appear in the live tor network. ## I2P I2P sounds similar to Tor in principle. Yet, I2P nodes learn about their network via gossip, not via a concensus like Tor. We'd need to discover I2P nodes by running I2P nodes. Also, I2P never engaged with the academic community for the pupose of studying metrics, never raised funds for building metrics infrastructure, and probably never collected historical data. ## Bittorrent We need not include trackers since too few trackers exist. If we can learn the torrents then we can however survey trackers for current stats from seeders. Again historical stat would not exist, but this could be easier than I2P if the trackers tell us their torrents. Assuming trackers never tell about their torrents then we'd need a list of interesting torrents, which sounds labor entensive. ## Slashing Is there anything that meaningfully obstructs validators from intentionally being slashed? tl;dr no.. We'll avoid slashing for most honest mistakes by doing [substrate#7398](https://github.com/paritytech/substrate/issues/7398) aka ["slashing reform"](https://hackmd.io/FY4MCfZCSZGkV-Ulo3VSRg) ([w3f#530](https://github.com/w3f/research-internal/issues/530)) which we require for bridges anyways. Yet, these "back certs" do not reduce slashing levels, do not avoid honest timeout mistakes [polkadot#1656](https://github.com/paritytech/polkadot/pull/1656), and do not mitigate intentional slashes. ### Corrolation We cannot meaningfully reduce "uncorrolated" slashes for candidate invalidity: Anytime an (invalid) parachain candidate gets backed then an adversary soon learn its approval checkers. At this point, if an adversary dislikes their odd against those approval checkers, then they need not reveal their own approval assignements for checking that candidate, and they can simply abandon their backing checkers to being slashed. Asymptotically, an advertsary with unlimited stake can make infinite profit by running this attack on Polkadot. We need real adversaries to run out of stake before this attack succeeds. Roughly speaking, if the backing group were slashed only a proportion 1/k then slashing them 100% exhausts their stake k times faster. In other words, we should ask adversaries commit k times more stake, which means k times more checkers _all the time_, and so slashing 100% supports k times as many parachains. It follows that a few validators wishing to beslashed 100% could always simply wait until they've enough validators assigned to the same validator group, and then produce a block on whatever parachain they like. If we've k groups, need 3 backers, and the adversary has n validators, then this happens with odds p = {n \choose 3} k^{-2} in any given era, so their expected waiting time is 1/p = k^2 / {n \choose 3} eras. We cannot improve this 2 so much by asking for more backers because backers contribute much less than apporoval checkers. We thus cannot mitigate against validators intentionally getting themselves slashed 100%, reporting the slash themselves. ### Rewards It's worse because a validator who slashes themselves could walk away with reporting rewards from their nominators stake. We should reduce rewards for reporting slashing of course, ala https://github.com/w3f/research-security-issues/issues/42 of course. Ideally, rewards would be less than minimum self take, but that's impossible. We've two respectable options however: - Reporting rewards could become a lower bound on self stake plus some multiple of commission, so a validator with low self stake and must have a high commission instead. - Reporting rewards could become "more manual", either by asking the council tip the reporters from treasury, or else by locking the rewards for long enough the council can manually reduce the rewards if appropriate. ## ssh-airdrop - Fetch ssh public keys via [`https://github.com/<username>.keys`](https://stackoverflow.com/questions/16158158/what-is-the-public-url-for-the-github-public-keys) - ssh key parsing - ['ssh-keygen -p -m PEM -f ~/.ssh/id_rsa' etc](https://stackoverflow.com/a/56300901) - https://rubygems.org/gems/openssl-additions - https://github.com/pwnedkeys/openssl-additions/blob/master/lib/openssl/pkey.rb
Last changed by  
 
Jeff Burdges
104

Read more

Jet KZG

e(A_1,B_1) \cdot e(A_2,B_2) = e([\alpha_1]_1, [\beta_1]_2) \cdot e([\alpha_2]_1, [\beta_2]_2) \cdot e( Z_{\mathsf{sec}} + Z_{\mathsf{pub}}, [\gamma]) \cdot e(C_1+C_2, [\delta]_2) \mathperiod

11/21/2023
Validator rewards in Polkadot/Kusama

Ideally, almost all rewards in Kusama/Polkadot would come from work done securing parachains like backing and approval checkers, including work supporting XCMP, and availability. We do need participation in relay chain block production and finality, so some rewards must continue, but their levels shall wind up greatly reduced.

10/7/2023
ark-substrate design choices

https://github.com/paritytech/substrate/pull/13031 https://github.com/paritytech/ark-substrate https://github.com/w3f/ark-scale/ Coordinates Affine coordinates and serialized forms differe in Arkworks and ZCash/BLST, but an easy conversion is given by https://github.com/MystenLabs/fastcrypto/tree/main/fastcrypto-zkp/src/bls12381

6/6/2023
Berkley Hackathon

We seek proof-of-concept cryptographic back ends, or interesting student papers or pre-specs, which should be polkadot flavored in the broadest possible sense. What is Polkadot? Polkadot is heterogenious sharded blockchian, which means two things: First, the shards called parachains each run different code, controlled by their own governance. Second, Polkadot itself runs an interactive cut-n-choose proof of correctness for the parachains, which remains secure under conventional Byzantine assumptions, so parachains interact easily without the extra complexity, latency, and poor security assumptions required by bridges. What cryptography works on Polkadot?

3/17/2023
Read more from Jeff Burdges
Published on HackMD