I don’t think we should modify Stake action. There are tools on betanet and testnet that will be affected. I suggest we introduce Stake2 action through a protocol upgrade. We’ll have to add a new host method for the Stake2 action to wasm, in order to add it.
That does mean that we still have to support the old Stake action and then later deprecated it once the protocol upgrade is done. We also need to add support for Stake2 in all the tooling. I am fine with this and would like to hear what other people think
So what would be happening with the signatures for the bridge if subset of validators continue using Stake actions?
That’s fine, given this migration should take more inputs we can indeed add method upgrade(new_code, migration_args).
Where validator would then call with new contract code and arguments that contain new secp and bls keys.
I think one important piece not discussed here is validator key management (not blocking for the main decision, but should be included in the scope of work). @eatmore mentioned potential issues with badly generated secp keys. It’s important to give tools to validators to manage all these keys well. Would be good to check if validators are doing anything outside of generating with generate-key tool and keeping file on disk. E.g. if they use seed phrase inference, hardware modules, etc.
Regarding the way validators register their keys:
In the long term, we should have Stake action and the corresponding host function accept a secp256k1 key in addition to an Ed25519 key. The proposed SetValidatorExtraKeys action may be suitable as a short-term kludge, but I would prefer a solution that avoids it.
Regarding the introduction of BLS keys:
I am firmly against introducing BLS keys at this time. Currently, there is no signature scheme based on BLS keys that is nearly as popular as Ed25519 or the secp256k1-based ECDSA scheme. Without knowing which exact scheme we are going to use, we also don’t know how exactly the keys will look like. While ETH2 has come up with some specific BLS-based signature scheme, we may want to use a different one in the future. Only after we make this choice, we can introduce BLS keys.
Regarding what exactly is going to be signed using the secp256k1 keys:
While this will probably be decided a bit later, I think that the specific data that is going to be signed with secp256k1 key (as written in the top post) is not optimal for the bridge use case. I think that a better choice will be to sign H(last_final_block_height, last_final_block_merkle_root, H(H(k[0], stake[0]), ..., H(k[n-1], stake[n-1]), total_stake)), where H is the Keccak variant used in Ethereum, and k[i], stake[i] and total_stake refer to the next epoch. Also, the current code for secp256k1 signatures, as implemented in nearcore, will hash any data passed to it using SHA-256. We would probably want to remove this and sign a Keccak hash directly.
I’m with @eatmore on hashing. Please don’t forget that hashes are to be verified on the Ethereum side, which means that precompiles for them are not the ones that we have in NEAR.
Supporting the point of the upgradability of pool contracts by @illia and others.
Is there any way of introducing threshold signatures or aggregated signatures to drastically lower the block validation on Ethereum side? @Illia@eatmore@alexatnear
Also, I’m not sure that 34% of the stake will be enough for checks. If we have 50% of the adversarial pools, they still can sign anything and send it to Ethereum. The block won’t be even connected to the chain at all, though it would be treated as correct. So, unfortunately, 67% required. Am I missing something?
The last but not least:
From the bridge product perspective, pessimistic bridge is an upgrade to existing implementation. Our current goal is to make existing implementation work correctly and smoothly. Pessimistic bridge is not in the OKRs for Q1. So there’s no burning need to introduce this protocol upgrade as soon as possible. I believe we can take some additional time to figure out how to implement the upgrade in details and make a smooth transition for all the participants.
Currently, Ethereum doesn’t natively implement all the operations necessary for BLS signatures (EIP 2537 will change this once it is deployed). While it may be possible to implement some of them manually (like we did with Ed25519), this will require a lot of work, and the gas cost will probably be higher than that of Ed25519 (although it will be enough to validate just one signature instead of 100).
Per the consensus spec, the guarantees of soundness and liveness only hold if less then 1/3 of stake is malicious. So, we already have this assumption.
Agree, we may better extend the discussion period.
ASFIK, threshold signatures can be implemented on top of many signatures schemes, including ECDSA. BLS is just simplifying the generation algorithm. But for us important only the checking phase, since it’s done on Ethereum. I must admit, that this increases the complexity of the solution, so it might take more time to do the audit.
The problem with implementing threshold signatures on top of ECDSA (and Ed25519) is that producing such a signature requires an interactive algorithm with multiple rounds of communication between all participants. Also, if one of the participants stops participating before the algorithm is finished, the entire process needs to be restarted. This makes it difficult to arrange with many validators any of which may go offline at any time.
I am with @eatmore (who is our only cryptography expert) on BLS: There are many BLS schemes, introduction of some BLS scheme into some clients does not mean it will be accepted, and even if it was decided by everyone does not mean it is going to be enabled. Here are two most recent historic cases:
So we don’t know which BLS scheme will eventually make it into Ethereum mainnet and whether it is going to be turned on at all. Given how much uncertainty we have around it, I think the potential small upside of rolling out BLS together with secp, instead of separately, is lower than the large risk of committing to wrong BLS scheme.
Everyone seems to be onboard with the necessity of adding validator secp key. However, there are some disagreements on the details.
For bridge, the exact message to be signed by the secp key is not finalized and I think we can take some more time to mull over this @eatmore@alexatnear@alex.shevchenko
For the protocol change, it seems that the consensus is that
it is better to upgrade through runtime directly by swapping the contracts.
There is some disagreement regarding whether we should directly modify Stake action or we should do it in a backward compatible way by introducing Stake2 action and deprecating Stake action later.
We do not want to introduce any BLS key at this point.
For changes in tools, it is mostly around near-api-js and near-cli and there is no need to change anything in wallet. The changes in near-api-js and near-cli are mostly around the change to Stake action (or adding Stake2 action).
A new staking pool contract and a new staking pool factory contract needs to be written.
Please let me know if I missed something in my summary and we plan to finalize the decision tomorrow after the public meeting.
There is consensus on the necessity of this change.
We plan to upgrade through introducing a new Stake2 action and not modify Stake directly. The reason is that the amount of work needed is very similar and it is preferable to upgrade in a backward compatible way.
Items that still need to be finalized
The exact message that is signed by the secp key.
The upgrade of the staking pool contract through runtime. We need to make sure that the new contract is also whitelisted and the upgrade process does not allow validators to arbitrarily modify the state.
It’s Daniel from stakefish. Any other details we should be aware about regarding the items that still need to be finalized? Sounds like consensus to move forward is established here. Will the remaining items be blockers on that end?
From a validator perspective probably not at this point. We will finalize the details of the contract upgrade in the upcoming weeks and post the details then. The contract upgrade will likely require some minimal effort from validators (e.g. sending one transaction).