Bloq is mostly done pulling together the work on the crosschain specification into a readable document, and I'm planning on an online Q&A livestream soon, but ahead of that I wanted to get some detailed answers out to the telegram channel for digestion; read on for more below!
When does the validator network go online?
This is probably going to end up in Bloq's court. The validation software is written, tested on testnet chains and functional as is; it could probably be prettier, but it works right now.
Who are the validators / how are they chosen?
Long term, we aim for a decentralized validator network. There are some crypto design problems we'd
like solved first, and this decentralization is on the roadmap for later; until then, I'd contact
me at email@example.com or Bloq directly through Telegram if you are interested in becoming a
Is there a term limit or expiration for validators?
Probably! The validator rules which will be published soon in draft form include a bunch of stuff
around penalizing / banning participants if they act badly, and we have started to work through
what sorts of bad behavior can be proven directly, and managed by the smart contracts.
This is the source of the desire for a lot of the data we put out in export receipts; stuff like sequential receipts with numbers that don't add up will generate instant penalties for validators.
The harder part is dealing with contentious forks, about which more in the documentation.
Do they use only Eth contracts or is their third-party off-chain software involved? If so who writes it and what framework? Who maintains the code base?
Validation server side is very, very thin. I want to say it's like 100 lines of node.js code.
The offline work revolves around making representations about the hashes of export receipts. The rest is done through smart contracts, although not limited to EVM smart contracts; anything Turing complete which can do sha256 can receive validations.
What is the timeline for the three validator roll out phases?
When they're ready. :)
The first step is getting Metronome launched on a second chain; I am not aware of any significant engineering hurdles for that, I think it's really just down to picking the next chain. Maybe we should have a community vote, that would be fun.
The least work would be to ETC, but anything with an EVM chain could be a great second target.
When will exports be allowed? When will imports be allowed?
You can export now, you just won't be able to import. Also, you'll really want to wait until that
next chain is added so you can export to a valid destination -- the contracts are picky about making
sure that an export is going to a known chain. At least if you ever want to import those MET.
At what point are minting shards removed from the source chain? At what point are minting shards added to destination chain?
I don't know what a shard is, but I think this asking about the specific timing for daily auction minting.
For example, here's a scenario I think the questioner is asking:
- Metronome launches on ETC.
- A user who may or may not have closed out the MET auction with a 5,000 ETH balance exports 1,000,000 ETH to ETC during the middle of a day. (Day 1)
- The user waits two days and calls import on ETC. (Day 3)
What is minted in the dailies and when?
As a side note, this is somewhat unlikely; there's an optional export fee associated with an export that goes to the validators, so if there were some MET placed into the fee, the validators would likely go ahead and finalize the import immediately in order to take their fee. But, let's talk about this scenario anyway.
- Day 1 Minting: 2880 on ETH, 0 on ETC
- Day 2 Minting: 2592 on ETH, 0 on ETC (Note that this assumes only 10mm MET issued)
- Day 3 Minting: 2592 on ETH, 288 on ETC
Note that some MET has 'leaked out'; in the design discussions, we agreed that this is okay, better than 'leaking in', and not easily solvable in a multi-chain distributed system. Also we all like a little bit of deflation, right?
What happens with minting if someone sits on an export for a long period of time?
See above, but in general this would be unusual; I think anyone can finalize a validated export as the system currently works.
What if validators disagree?
Many, many pages are written about this, are currently in editing review, and many more will be written. The answer is 'it depends'.
The slightly longer answer is that the system is going to distinguish between disagreement on hashes that in themselves do not contain rule breaking (a contentious blockchain hardfork, but nothing to do with us), and disagreement on hashes that themselves do contain rule breaking, (bad behavior by some validators), and agreement on hashes that all contain rule breaking (bad behavior by all validators for a given chain).
If things get bad on a chain, the Metronome solution is to punish that chain by not allowing them to export to other Metronome chains; they're booted from the network that's "safe" and rule abiding.
In other words, feel free to put Metronome on your cancer chain that's run solely by fiat or lawsuit or whatever crazy plan you have, but if Metronome on that chain disobeys the rules, it's going to get shunned by all good and safe Metronomes, and unless the cancer chain gets its shit together, any MET sent there will be lost and unable to come back to safety and sanity.
The general plan is a yellow card / red card system where yellow cards allow relatively easy re-activation and red cards require significant effort.
Can anyone be a validator?
That's the goal, but right now I think the answer is "yes" if you mean it in a sort of Ratatouille way, "anyone can cook", but "no" if you mean "can arbitrary Ukrainian teenagers join the validator network at will?"
Again, if your business or group is interested in validating, please contact me at firstname.lastname@example.org or Bloq directly and let us know.
Can a validator be voted out by the community in an automated way?
Voted, probably not, we're aiming for minimal politics.
Booted because doesn't follow rules? Yes.
Booted because slow? Probably yes.
Booted because keeps validating different hashes than others? Yes.
How long does an export/import take? Is there any plans to speed it up to be within seconds?
Early days, it could be seconds - our integration tests run on that time frame, just down to block approval times with some wait for forks.
Later, it may slow down (Painful I know!), it's a trade off between decentralizing validation and speed. Later again it will probably speed up as we get some form of mimblewimble/ZKSnark support in that allows non-interactive proofs to be made. But that's definitely later not "later this year".
AION is doing some interesting stuff here on fast or secure crosschain work, where you can sort of pick your poison, and that's all pretty interesting too. I'm curious what people will come up with, definitely send ideas around and start filing MIPs.
Are there any limitation to how much MET I can export/import?
You can only export as much as you have. You can only import as much as was exported to you.
Are there any limitations on how often I can export MET?
As often as you can post txs that validators will validate.
What happens to an export/import if the TX runs out of gas? Can I try again? What safeguards are built in to ensure no loss of funds in the cross-chain transition?
On Ethereum or related EVM chains, if you run out of gas, the chain state is reverted to the start of the call, and so you can go ahead and re-export if you run out of gas.
The same on import.
We've tested the shit out of the crosschain functionality, but there are always risks. And, in a system like this, recourse is hard, because nobody controls it.
I guess a path for reversing a sort of TheDAO-like event would be the publication of a new Metronome contract on a chain, validators agreeing that's the "real" Metronome across all the other chains, and a special one-time validation exception code being written into the standard validation, audited and published.
In short, we've tried as hard as we can to make all this bomb proof, and we'll be soliciting as many nasty test cases as possible ahead of launch.
What chains will be supported in the next year? Do we have a timeline?
Above my paygrade. :) I think the community should engage and pick. We'll need validators willing to run code on those chains' full nodes, which I think rules out shit chains or those with questionable codebases; best would be an EVM chain with similar semantics and block hashing to Ethereum that's managed by a well respected team.
Who will run customer support for the validator network?
That's a little like asking who will run customer support for Bitcoin miners. If there is such a group, I'm not aware of it. Validators are going to have to either run standard code or write their own that works per the rules, and not screw things up, otherwise they won't get to participate in the network.
What is the minimum number of validators required? What is the maximum number of validators allowed?
I would say two is good enough to start, but three would be better. Max validators - the nearterm roadmap is going to be practically limited by gas costs, latency and so on for a large number of validators.
I'd say any more than 5 is just going to be expensive and worthless. Especially consider that they'll need to cross validate to multiple chains.
Long term, the goal would be an arbitrarily scalable validator group, but some problems become harder in this world; under most rule sets you can imagine, validation becomes either mining or stake mining. (Oooh, custom Metronome mining hardware anyone?)
So, this is an area where research is needed is the upshot; to me the fundamental rules are that
- No more than 10mm + 2880/day shall ever be issued across all chains
- Humans be involved as little as possible
The rest of it is sort of up to everyone to see the best way to accomplish those goals!