Some initial thoughts on needed interfaces/requirements for parathreads #6625
Conversation
| Collators need to be able to bid securely in auctions for getting a slot. Idea: | ||
| Have restricted (proxy) accounts which are restricted to bidding on parathread | ||
| auctions for a specific `ParaId`. This can further be restricted to just a bid | ||
| per day/per hour/.... whatever is suitable for the parathread and greatly | ||
| reduces possible damage if keys are leaked/lost. |
There was a problem hiding this comment.
These should be session keys. An account on the relay chain could set its current collator session key. We could then let collators send unsigned transactions for bidding. If some locked funds on the account setting the collator key isn't enough, we could always deduct fees for the unsigned transaction from the account. The payment for the block would then always come from the account that set the keys. No one could then do that much bad with session keys if they are leaked, besides trying to bid for slots and burning the money in this way.
There was a problem hiding this comment.
https://github.com/orgs/paritytech/projects/67/views/1?pane=issue&itemId=19145863 Have you seen this? I think a different idea is to have collators store a "hot" key which is a proxy that is only allowed to issue bids.
Collators are currently not registered on the relay chain, and any account can issue a bid "on behalf of" any collator. There is no real harm in buying blockspace for arbitrary collators, because the account paying for the blockspace is the one on the hook for the bid and the collator would receive any block rewards / transaction fees.
There was a problem hiding this comment.
I think we should support both. Giving the people more freedom on how to implement it. Either a collator is "pre-registered" and then uses an unsigned transaction to do the bidding on its own or we have some account that sends some BidFor { collator: Key, bid: Balance}. Internally both then map to the same function bid(collator: Key, bid: Balance)
There was a problem hiding this comment.
It is usually better to have one way of doing things than 2. What benefit is there for collators to pre-register?
There was a problem hiding this comment.
When you pre-register a collator public key you wouldn't need any private key stored on your collator that has access to funds on the relay chain.
There was a problem hiding this comment.
You would also need to have enough funds to pay transaction fees and constantly ensure that the account isn't running below ED. I mean you are right that these aren't hard technical points or change the fact that an attacker could still attack by draining the funds for bidding, but I think it makes the usage easier. But this isn't such an important topic and we could still later open the route for unsigned transactions. This isn't really any point that will change the implementation fundamentalally.
There was a problem hiding this comment.
After a little research I like the proxy approach better as well (for now), because signed extrinsics come with a bunch of security features by default, which would need to be re-implemented for the unsigned case. Might not be a big deal, but I generally like not re-implementing the wheel, especially when it comes to security relevant matters.
You would also need to have enough funds to pay transaction fees and constantly ensure that the account isn't running below ED.
Wouldn't the same hold true for unsigned extrinsics signed by the CollatorId? Orders would still not be free, but will be charged to some account (coupled to the CollatorId).
There was a problem hiding this comment.
Wouldn't the same hold true for unsigned extrinsics signed by the
CollatorId? Orders would still not be free, but will be charged to some account (coupled to theCollatorId).
By orders you mean the bids? When you are using the proxy approach, you will need two accounts with funds in it. The account that is used to bid (which has all the funds in it to pay the bids) and the proxy account that controls the bidding (this is the account stored on the collator and requires funds to pay the tx fees). The collator will send transactions using the proxy account to bid with the bidding account. When we would have an unsigned extrinsic you would not need any funds to send the unsigned extrinsic as unsigned extrinsic by design don't pay any fees by default. Then you only need to have funds in the bidding accounts to pay the bids.
There was a problem hiding this comment.
Got it. Yeah, I already noticed that proxy accounts are a bit of a pain from the user interface perspective. But using an unsigned extrinsic to avoid the bad user interface of proxy accounts seems a bit backwards - would it be hard to improve proxy accounts to benefit all use cases and not just parathreads? I don't see a fundamental reason why fees for transactions of a proxy account should not be paid by the proxied account - in fact we would need that for using the proxy account abstraction here anyway, because I am aiming on customizing fees to pay for the order as well, if that would be charged to the proxy account instead of the proxied account, then this would become rather pointless.
Looks like looking into customizing fees might be pointless after all.
By orders you mean the bids?
Yes orders are bids, because in our current model they are actually not bids anymore, but rather orders - which are either valid or invalid, but other than that the same.
There was a problem hiding this comment.
would it be hard to improve proxy accounts to benefit all use cases and not just parathreads?
https://github.com/paritytech/substrate/issues/7054
because I am aiming on customizing fees to pay for the order as well
Fees are currently based on the weight and you can not that easily change this. However, with some custom signed extension it should maybe be possible.
|
|
||
| The user can apply for a slot by placing a bid extrinsic. This bid will contain | ||
| some price the user is willing to pay for a core. These extrinsic go into a | ||
| transaction pool, as other extrinsics. |
There was a problem hiding this comment.
it would shed a lot of light if you would specify the parameters of that bid extrinsic.
| node side? If we don't check signatures on the node side, then how can we be | ||
| spam resistant? | ||
|
|
||
| Then the block producer should put bids into the block, limited by some maximum |
There was a problem hiding this comment.
This implies that the bidding is basically off-runtime. What's the justification to handle this? I presume the parachain protocol has made similar decisions in other places as well.
There was a problem hiding this comment.
Basically weight limit. Block producer can not just put everything that is available in there, no matter what. But we already revisited how bidding works, so this is pretty much obsolete already.
| #### Runtime Implementation | ||
|
|
||
| More details on auctioning | ||
| [here](https://www.notion.so/paritytechnologies/Exotic-Scheduling-Auctions-53148e8d90d74411ab445b7d1dd6cfc8). |
There was a problem hiding this comment.
This is outdated as well, right?
|
|
||
| } | ||
|
|
||
| struct PendingAvailabilityClaim { |
There was a problem hiding this comment.
This needs to include candidate hash, at least if it is intended to replace the fn availability_cores() runtime API. The provisioner in asynchronous backing needs to know which candidate it has the bitfields to include, so it can provide a candidate that's a child of it, if necessary.
No description provided.