Skip to content

Instantly share code, notes, and snippets.

@ltfschoen

ltfschoen/kusama_chats_notes.md

Last active September 11, 2019 02:21
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save ltfschoen/1956423a853ae606351eb60592f6dc25 to your computer and use it in GitHub Desktop.
Save ltfschoen/1956423a853ae606351eb60592f6dc25 to your computer and use it in GitHub Desktop.
Download ZIP
Summary of Kusama Validator Lounge chats up to 11th September 2019
Raw
kusama_chats_notes.md

Summary of Kusama Validator Lounge, Kusama Watercooler chats up to 11th September 2019

  • prometheus exporter - https://github.com/w3f/substrate-telemetry-exporter

    • it expects to run in the same host as a telemetry backend
    • you can run your polkadot nodes in different hosts and configure them to send telemetry data to specific remote telemetry backends as usual, so that you can send data to a backend with the exporter connecte
    • do the same as in the Dockerfile, from a clone of that repo you can run yarn && yarn start

  • polkadot secure validator - https://github.com/w3f/polkadot-secure-validator

    • @anson:web3.foundation, @federico:web3.foundation
    • terraform takes care of it on the complete secure validator setup, that's why i wasn't understanding this is how it is done for the public node on GCP https://github.com/w3f/polkadot-secure-validator/blob/master/terraform-modules/secure-validator/main_gcp.tf#L5-L29 (ssh port not strictly required)
    • ansible playbook with one validator and public node. changed the ips and users, install and service is running. public node not visible on telemetry since it doesn't send data to any telemetry backend by default, so you need to add --telemetry-url ws://telemetry.polkadot.io:1024, then reload the config and restart the service systemd daemon-reload && systemd restart polkadot.service. check the nodes' logs to verify that all is working as expected. for private validators you only need the vpn port open as all connections should go through it (block everything except vpn for incoming connections, and p2p port should be closed for outgoing too, whilst outgoing connections may be otherwise more flexible to allow upgrades); public nodes need both p2p and vpn ports open, this is done here https://github.com/w3f/polkadot-secure-validator/blob/master/ansible/roles/common/tasks/main.yml.
    • to use https://github.com/w3f/polkadot-secure-validator/blob/master/ansible/inventory.sample you should change the IP address and the ansible_user based on my infra providers and then node sync, include [public:children] and [all:vars] entries as in https://github.com/w3f/polkadot-secure-validator/blob/master/ansible/inventory.sample other than that yes, you should customize the inventory file with your ip addresses and ssh users, then from the ansible directory in a repo clone run ansible-playbook main.yaml -i /path/to/custom/inventory. The sync command both creates the underlying infra with terraform and then provisions it with ansible, currently it can't be used just for the provisioning stage
    • the requirements for using the secure setup before doing yarn sync is to open accounts with a few services as described at the end of this section https://github.com/w3f/polkadot-secure-validator#how-to-use?
    • polkadot systemd unit template for the validator https://github.com/w3f/polkadot-secure-validator/blob/master/ansible/roles/polkadot-validator/templates/polkadot.service.j2
    • use the following format, and turn off telemetry with --no-telemetry and look at ansible roles for example implementation 
      --listen-addr=/ip4/VALIDATORVPNIP/tcp/30333
--reserved-nodes /ip4/PUBLICNODEVPNIP/tcp/30333/p2p/PUBLICNODENETWORKID
    • "Private (validator) node" section in README.md is the systemd script for the min. spec of 1x validator (with 3x public sentry nodes), where IPs are those set up for WireGuard VPN (virtual subnet).
    • set-up with ansbile and a update rolls out on node-software what way of updating do you advise ? The ansible script downloads the polkadot binary, would compiling the binary and replacing it be sufficient
      • sure, regular binary upgrade should be ok; this could be handled by ansible too but not currently implemented
    • wireguard setup validator private and 2x sentry by melea - https://gist.github.com/iammelea/2b9237f0478a33ca0119be95bb36bc33
    • monitoring
      • having the ability to add a set of telemetry backends in the ansible inventory file for the validator and/or public nodes to connect to them. If it could help monitor and alert for this kind of thing, that would be good... 'Both public nodes are way ahead and it connects to one or none'. Can use node log monitoring to check on node connections but not sure about checking how many blocks your nodes are behind last finalized block... Maybe can do from logs but I need to look at log monitoring apps ability to analyse and compare text strings / data structures - not something I know much about.
      • Most in here will v. knowledgeable of log monitoring apps and what they can do already but, looks like Graylog can do such stuff: http://docs.graylog.org/en/3.1/pages/extractors.html

  • validator service list

  • sentry nodes

    • wss://pool-api.debank.com:2053/kusama/ (for querying only, no extrinsics yet)

  • changing session keys

    • grandpa has eras, which are broken up into sessions, babe has epochs, which are broken up into slots, right now, these are roughly:
      • grandpa: era: 24 hours, session: 4 hours (i.e. era is like 6 sessions)
      • babe: epoch: 4 hours, slot: 6 seconds (i.e. session/epoch duration same)
    • if you set your session keys on your stash and it's intended to validate, but you then want to switch your validator node to another one, you first stop validating. you can't stop validating in the middle of an era, otherwise you'd be slashed based on the rest of the era and possibly subsequent eras, before being kicked out. you'll be slashed until either your stake is too low to be elected or you manually signal (with your controller key) that you no longer want to validate. other nodes in the network have no idea if you're not responding, are offline, or have crashed. if your node has crashed or is offline, it can't really make or broadcast, respectively, its decision to stop validating, which is why it needs to come from the controller. the "unstake threshold" is triggered when other validators report you offline. so you could miss one round of voting, but 3 validators could report you offline. then change the session keys (extrinsics --> session --> set key), or click the little gear in staking app next to the stop validating button and there should be an option to change your session key
    • new session keys are effective in the next session
    • when you make the rotate_keys RPC call to setup their validator keys (the result from rotateKeys is a concatanation of the public halves, and these private keys are put on your node by rotateKeys). These private keys must be in your node.), it's onto your own validator node (not the default public node), the node itself then generates the keys, stores the private keys locally and returns a concatenation of the public keys. you need to tell the chain which Session keys correspond to your Controller account by signing the public session keys (the "result" from rotateKeys) with the private key of your Controller. This is what set_key in the Session module does.
      • Session keys in the client via RPC. You can do this through Polkadot JS connected to your local node (Toolbox > RPC Calls > author > rotateKeys()). If you are doing this, make sure that you have your Polkadot explorer attached to your validator (in Settings)

You can have any number of sets of Session keys in your node. It will see which ones are registered on-chain and use those - either make the RPC call to your node using the Polkadot UI or execute the curl command on your validator

  • process of swapping your validator over to another machine?

    • you can do this by spinning up another machine in the same era, generating session keys, and setting them via set_key, they don't take effect until the next session, at which point your new validator will take over (as your old one doesn't have these new keys) and you can turn off your old one

  • block production and finalisation times

    • higher thoroughput -> scale with parachains
    • lower latency -> use plasm or other L2 solutions
    • block production via BABE is separate from block finalization via GRANDPA https://research.web3.foundation/en/latest/polkadot/GRANDPA/. GRANDPA is fast, but it's still going to lag behind production (by definition - blocks need to be produced before they are finalized). for faster finalization times, you can always make a parachain with a different algorithm. but there are always going to be trade-offs to this. if you have 1000 validators with a 30 second block finalisation time is fast for this era of blockchains, but may not be enough for real world problems
      • major factor in the decision to decouple block production from finality - many blocks can be finalized simultaneously so it won't be "behind" indefinitely, and also lack of immediate finality means the chain won't freeze in this situation
    • polkadot differs from tendermint in that you can have blocks that are unfinalized and the network won't break

  • bonding

  • claiming KSM

  • validating

    • a validator with 16% control is likely already too risky for most validator operators (since punishment scales with increasing stake)
    • assuming you have enough DOTs, or enough stake nominates your validator, to ensure that your validators remain in the validator set, running multiple validators will result in a higher return than running a single validator
    • PoS is not sybil resistant. a validator run by the same person on different infrastructure is (unfortunately) effectively indistinguishable for the chain and network security to a validator run by a different person on different infrastructure
      • NPoS in Polkadot - https://medium.com/web3foundation/how-nominated-proof-of-stake-will-work-in-polkadot-377d70c6bd43
      • exchanges may offer multiple centralised validation services, but if they do they are incentivized to do it as decentralized as possible as they take on greater risk if they share infrastructure due to correlated slashing. issue on Cosmos network with PoS due to centralisation with exchanges not charging fees and essentially destroying the market for other staking as a service company's, likewise an issue at EOS
    • How much KSM need to validate blocks?
      • If the networks is open to 50 validators and now only 29 + 6= 35 (15 open slots) no need more than the last, just delegate some X KSM but beware when POA ends then to validate need more KSM than the #50 if only 50 validators slots. just that
    • https://guide.kusama.network/en/latest/
    • https://guide.kusama.network/en/latest/try/validate/

  • nominating

    • centralisation acts as a magnifier for slashing (punishment scales with increasing stake), so if you do nominate a whale with any significant amount of stake (i.e. 40%) and their datacentre/infrastructure/whatever goes down, then you'll be wiped out, whereas if you nominate an unpopular 0.1%er then they can misbehave even more before you'll be hit at all, just because the 40%er going down will be a correlated event
    • nominated as a validator, how would you see the amount that is nomiated to you ?
      • you don't. there's no such thing as "nominating for an amount". a nominator either approves of a (would-be) validator or they don't. per-era, each nominator has an exposure to 0, 1 or more active validators. this is the amount of their stake that may be slashed if that validator misbehaves. it's determined by the system and is stored in state, but i don't know if there's any way to see it in the UI yet
    • so if the value bonded is 10 and the nominator is distributing it over 5 validators, its distributed equally to all?
      • no, it has a chance of being assigned to each of the 5 validators in any possible combination. the system determines the assignment, such that it is optimal for the system. as a nominator you only get to approve of a validator candidate (or not). you can't specify anything more. so there's no way of quantifying how much exposure you might eventually be assigned to them. you have to assume that all of your stake might be allocated behind any individual validator for any era. if that's a problem, then you would want to split your stake into different accounts and nominate different validators from each account. doing this, however, will ultimately mean a less optimal allocation, which will mean lower profits. (not taking into account the risk of validator-misbehaviour)
    • Does the system also split the nominators bonded value among the selected validators or does it always allocate the full amount to one validator ?
      • it splits the bonded value optimally between 0, 1 or more of the approved and active validator candidates
    • list of Nominators from Afri - https://www.pastiebin.com/5d73fee3c5d04
    • you won't see constant updates of nominations. Running the Phragmen algorithm is quite heavy, computationally, so we can't be running it every time. That said, Nominators is a public storage item, a mapping of stash => vec[validators], so it may be possible to query the chain state and run offline. (don't take my word for it though :)). Phragmen only runs when the era changes
    • staking.nominators, but it doesn't contain the specifc amount of token staked to one validator. That's what Phragmen computes. It contains a nominator as a key and a list of acceptable validators as a value
    • https://medium.com/@fire_cx/how-to-nominate-a-validator-on-kusama-652e12feb326
    • claimed KSM, follow this guide for how to nominate during Kusama's soft-launch period. The first 50 well-backed validators will be Genesis validators on Kusama
    • how to choose validators?

  • blogs

  • PoA vs NPoS

    • soft launch (when network is PoA)
      • POA no rewards, Only one sudo key for governance, Sudo key now = W3F. Eras will not change during soft launch. ForceEra https://github.com/paritytech/substrate/blob/master/srml/staking/src/lib.rs#L614 is set to ForceNone during soft launch, which "avoids a new era indefinitely.". Some of the functions of staking module are enabled, but the voting distribution calculation part is not. So we can't preview the result of NPoS algorithm yet. validators aren't part of the staking system at all. staking.setController won't change until there is an era change, But the soft launch is all a single era, so for right now, it wouldn't take effect until after the NPoS upgrade, You would have set a controller when you bonded funds
    • NPoS

      • They've suggested that they'll make the switch once they have 50 validators lined up.

      • 25 Aug - It's possible to nominate today, but rewards won't start being paid out until after the transition to PoS, roughly in weeks time. You can nominate up to 16 validators concurrently iirc. Changing nominations does not require unbonding. Takes one era 24 hours on kusama (on alexander its 1 hr). Validator sets change every era. Slashes can happen up to 28 days afterward, Maybe longer but it has to be at least that since that's the unbonding period. trying to slash after the unbonding period would violate security assumptions. Don't forget that Phragmen will be shifting your stake among the nominated validators continuously as well 24h after redelegation of your nomination you are not slashable anymore on the old node offenses, if you change for a new era and no longer nominate a validator then you won't be slashed if that validator does an offence in the new era, But you could be slashed if that validator is found to have done an offense while you nominated it

      • changing nomination takes 1 era, but doesn't require unbonding.

      • Bonding means locking funds in the staking system and once they're there can be used to validate, nominate, or change nominations without needing to unbond

      • https://research.web3.foundation/en/latest/polkadot/NPoS/

    • https://research.web3.foundation/en/latest/polkadot/Availability_and_Validity/
    • https://wiki.polkadot.network/en/latest/polkadot/learn/phragmen/

  • kusama repo

    • What version of substrate will Kusama Network use
      • branched from substrate master, so substrate 2.x

  • staking and validating on kusama

  • testnet dots or KSM and validation workflow

    • create an account off-chain, but only becomes an account on-chain once it has funds greater than the existential deposit
    • claim/obtain KSM tokens
      • claiming via the claims process
      • or Kusama (KSM) Grant Request Form - https://docs.google.com/forms/d/1-JxlJqt8DA0E3K0QX0Gc20rF02-aqDn6r_rzkB4LaMk/viewform?edit_requested=true (i.e. for a larger amount of KSM)
        • validators to whom w3f has given a KSM grant (who don't have their own KSM from claiming): if you'd like to receive some of your KSM earlier in order to be able to signal intention and get nominations, let us know and we'll try to sort you out - Gav
      • or obtaining ksm via third party to start validating
        • if you know someone with a DOT allocation who hasn't claimed KSM, they can sign your claim message for you
    • use tokens for voting/staking
      • send funds from stash account to controller account (KSM to pay for transaction fees of issuing the nominate or validate command), which is used for submitting extrinsics
      • you can change your stash into controller after creating a bond
      • kusama won't allow token transfering in the soft launch period, so in the meantime until token transfers enabled you need to add both a stash and a controller account to the genesis file (chainspec) and submit intention to validate https://github.com/paritytech/polkadot/blob/master/service/src/chain_spec.rs ("/home/ubuntu/polkadot/service/res/kusama.json"), it contains the bootnodes for the network.
      • chainspec depends on the chain's runtime. chainspec.rs tells the runtime to load the kusama.json
    • https://faucet.polkadot.network, but transfers of KSM not enabled until NPoS and friction faucet

  • how to validate

    • follow the instructions for bonding and setting session keys to allow you to signal your intent to validate https://guide.kusama.network/en/latest/try/validate/#bond-ksm
    • polkadot docker
    • Chevdor polkadot Docker image - https://hub.docker.com/r/chevdor/polkadot/tags
      • docker run --rm -it chevdor/polkadot:kusama polkadot
      • docker run --rm -it chevdor/polkadot:0.5.1 polkadot --name meleabucles
    • Emiel polkadot - 
      docker run -it polkasource/substrate-client:kusama-v0.5.1 --validator --name crazyone
bonded, create/set session key (node you call rotate_keys on must be your validator), i press validate

docker run -p 9944:9944 -it polkasource/substrate-client:kusama-v0.5.1 --validator --name crazyone --ws-external
then connect to ws://localhost:9944 endpoint should work. if you're on the cloud it gets more complicated because of the cross origin policy on the UI requires you to have an SSL cert, so recommend building a binary, then you will be able to use the curl command no problem
    • Official Polkadot Docker images - https://hub.docker.com/r/parity/polkadot
    • releases
    • setup environment 
      # Setup environment
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y
source $HOME/.cargo/env
apt install make clang pkg-config libssl-dev build-essential libssl1.0-dev

# Get Kusama source code
git clone https://github.com/paritytech/polkadot.git
cd polkadot
cargo clean
git checkout v0.5.1
git pull origin v0.5.1

# Build and install Rust binary
./scripts/init.sh
cargo install --path ./ --force
    • systemd 
      [Unit]
Description=Polkadot Node
After=network-online.target
[Service]
User={user running polkadot}
ExecStart={path to polkadot bin}/polkadot --validator --name {validator name} --key {validator key}
Restart=always
RestartSec=3
LimitNOFILE=4096
[Install]
WantedBy=multi-user.target
    • transfers will be enabled in the NPoS phase. You can prepare to validate without transfers. make stash == controller, and call set_key with your session keys. Prior to NPoS, the logic in the runtime doesn't prevent balance transfers from occurring, it prevents extrinsic calls from anything other than the Staking, Claims, Session, and Sudo modules. https://github.com/paritytech/polkadot/blob/master/runtime/src/lib.rs#L132 is the match statement that prevents balance transfers. It's not blocking balance ops on the state, it's just allowing calls from a very limited set of modules

  • telemetry

    • troubleshooting
      • if have 0 peers, only need TCP 30333 open for Kusama.
        • only need 9944 (default ws port), and 9933 open for Alexander.
        • check can initiate TCP connection from external IP to the node
        nc -zv $NODE_IP 30333
        • use flags --in-peers 100 --out-peers 100

  • setup kusama

    • go to https://polkadot.js.org/apps/#/settings
    • go to "setting" and enable "custom endpoint"
    • enter wss://canary-0.kusama.network into the "remote node/endpoint to connect to"
      • check adblocker not stopping me connecting to the wss
    • click "save and reload"

  • collator communities

    • room where teams can share ideas about economic models for their parachains. Some ideas to get started: inflation, airdrops, proof-of-work, token-less parachains.

  • validator status

    • goal is 50-100 validators at genesis. it's expected that block finalization will lag behind block production, although it generally should not be far behind

    • currently is a soft launch period (PoA chain network with no staking), so there are only authorities (not validators), validators only allow to express their intention by signalling and during this period (i.e. staking module allows bonding, nominating, and issuing and intention to become a validator, so 50-100 well-backed validators are ready when there is a final runtime upgrade that includes NPoS and Kusama's genesis governance), no rewards given, hence there are nodes shown who have applied to be a validator but are hung up (yet to be elected) on next up list on polkadot/apps despite the upper limit number of validators being 50. to signal follow the process as if you are validating - set your session key and hit validate. you get added to "next up" as expected, but you won't be added to the validator set until the network is live.

    • those that become validators after the PoA phase (when it becomes NPoS) are those with the highest amount at stake (including nominators' stake)

    • validator_payment - service fees where validator set

  • validator preferences and staking/unstaking in Polkadot UI

    • "unstake threshold = 3", where the unstake threshold is added to a common offline grace number for all validators.
    • node identicon with a red circle marker "4" (means it's been offline 4 times)
    • "reward commission" is number of dots Per payout/era (approx 4 hours) - All validators will be paid the same first. Then it deduct how many dots you would like to receive by this commission setting. And then distribute the payout to the nominators by their nominated percentage. if no nominators you get your whole proportion of the reward, otherwise if you have nominators set it to your cost of operations and how much want to earn
    • unbond period is 28 days

  • slashing

  • earnings / incentivized network

    • about:
      • incentives to validate on top of Polkadot.
      • One percent of DOT tokens at Polkadot genesis have been reserved as an eventual incentivisation grant to Kusama’s stakeholders and community. The precise mechanics of this have not yet been finalised.
      • people will want to participate in governance and bond parachain slots, possibly in the future there will be some kind of communication between the Polkadot and Kusama networks
    • payments for kusama stakers is about the same as what is planned for dot holders i.e. 1000 to 2000 KSM per month per validator node, or around that number, it depends on the validator slots & total KSM bonding rate
    • the first set of validators will be taking on the most risk and the most potential reward as well.
    • https://wiki.polkadot.network/en/latest/polkadot/learn/staking/#inflation you can refer to the graph here to relate the percentage reward compared to the percentage of supply that is bonded for nomination or validation. rewards is recorded per session & distributed for each era
    • https://wiki.polkadot.network/en/latest/polkadot/node/guides/validator-payout/

  • reward scheme for validators and nominators?

  • inflation

    • https://research.web3.foundation/en/latest/polkadot/Token%20Economics/#inflation-model
    • that's just network-wide supply inflation. Rewards for individual validators depend on many other variables you can see throughout that page, but it should be around 20% assuming the target of 50% or supply bonded is achieved.
    • it'll be 20% if exactly 50% is effectively staked (i.e. actively backing a current validator); if less than 50% is effectively staked, then the tokens that are allotted to active validators will get more than 20% reward; if more than 50% then it'll be less

  • election of validators

    • The reason for the election algorithm is to achieve as close as possible to an evenly-staked validator set. Validators each have one vote, regardless of stake, and rewards are equal per validator, not stake-based. We want to avoid the situation of a small number of validators controlling a large amouunt of the network. By allocating your stake via phragmen, it maximizes nominator rewards. If you want to set your nomination weights yourself, you can create multiple stash accounts and just nominate one validator with each one

  • apps extension

  • v0.5.0 vs v0.5.1

    • v0.4.0/0.4.4 is Alexander testnet
    • v0.5.0/0.5.1 should just execute wasm instead of native. That's the whole forkless upgrades feature
    • chevdor/Polkadot image that is fairly recent. The main visible diff for validators is that --key is gone and you pass the session key thru a RPC call. Remove your keystore file, connect Polkadot explorer to your validator (in Settings) if you're using the UI, generate keys and run author_setKey() and later run author_insertKey(), but generally it is recommend instead now to just use curl or the Polkadot UI if its connected to call on your local node author_rotateKeys (let the node generate keys) and then call author_setKey() with output of that to set the session keys
    • 'master' branch may work but it's not supported long term. to be sure things work as expected, use v0.5 branch and releases.

  • misc notes

    • Just because balance transfers are disabled doesn't mean you can't call extrinsics or that balances can change via fees/slashing/etc. It just means that extrinsic calls from the Balances module will be rejected. Setting the Session keys (called from controller to associate your local node with it) from the Session module (extrinsic set_key()) charges a fee and is in no way affected by the fact that the Balances module is disabled.
    • Because the Balances module is disabled, you will not be able to transfer from a stash account to a controller account. You can, however, have your stash account be your controller account. If this is still not allowed in Polkadot JS, this is a UI issue and not a protocol limitation. I'm sure it will be fixed soon. Once NPoS goes live, then you should change your controller. You can do this without any inturruption to validating. On the other hand, if you do have two KSM accounts, then you can use distinct stash/controllers.
    • If you plan to run validator setups but don't have any KSM, please post here and we will get you some before the soft launch period ends so that you can signal intent. It won't be enough to be elected into the validator set, so you'll have to get nominators. Edit: even better, fill this out: https://docs.google.com/forms/d/1-JxlJqt8DA0E3K0QX0Gc20rF02-aqDn6r_rzkB4LaMk/viewform?edit_requested=true

  • parachain auction

    • if a bidder wins an auction for a slot, what happens to the DOTs? it will lock up for 2 years and then released back after 2 years? the bidder cannot stake the DOTs that is locked for a parachain slot. the cost of parachain slot is 1) missing rewards from not staking those locked DOTs, 2) forcedly exposed market risk of DOT price for 2 years, 3) capital opportunity cost for amount of DOTs locked

  • addresses on kusama vs polkadot

    • why does kusama has different addesss format from polkadot?
      • because Kusama and Polkadot are intended to connect multiple chains together, so it's helpful to know which chain you are referring to when you give someone an address

  • anonymity

    • Anyone can see the number of DOTs allocated to an ETH address in the claims contract. Yep but their is not link between a validator and an ETH account until you claim KSM. Which is exactly my point.
    • you don't need to be public in the phase of the network (or ever). validators will have to be convincing. Will you trust a totally anonymous validator?

  • parachains on Kusama

    • until Cumulus is ready there probably won’t be any parachains. Cumulus will launch around September or October and then it will be much easier to attach a parachain. The relay chain will probably have 5-10 slots initially and scale over time.
    • Would it be possible to connect a parachain both to Polkadot and to Kusama? If not, how can we migrate parachain from Kusama to Polkadot?
      • Yes sota if you win a parachain slot bid on both chains, I’d say building on kusama would be easy to port onto polkadot as it would be the same logic, assuming kusama will just be a lower opportunity cost / overall to secure a slot + less audited initially. Eventually there are plans to make kusama relay chain on top of polkadot relay chain too so it’s as if the ecosystem in kusama would exist on top of polkadot.
      • instances of a parachain on both relays. But trying to keep one parachain in sync on both Kusama and Polkadot.. I can't think why to do that. you have to win separate slots for each chain
      • I guess in theory collators could be using the same source to create their blocks, but I think it wouldn't make sense to be connected to both chains then since it would be attackable under the weaker security chain.
    • share slots from more than one parachain?
      • We are trying to make it possible with Plasma (see Plasm)

  • bridge

    • Well, a bridge between relay chains could actually be done using simple collators + relays, it would just need a special parachain slot on both the Kusama and Polkadot side that acted as the interpreter between the two.

  • collators

  • parathreads

  • scripts

import { setAddressPrefix } from '@polkadot/util-crypto';

setAddressPrefix(2);

const validatorMap = await api.query.staking.validators();
let validators = [];

for (let index = 0; index < validatorMap[0].length; index++) {      console.log(validatorMap[0[index]);      
 validators.push({        controllerId: validatorMap[0[index],        
 ...validatorMap[1][index],     
 });
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment