RFC11: on chain activation

[vihu]

Summary

Add RFC11: on chain activation

Fixes: #2209

[elitegreg]

I think the biggest issue is with recycling resources. That needs to be done as part of this implementation. That flows through to the migrations which need to be reworked. There's a bunch to talk about with migrations that we can all go through as a group.

[vihu]

I think the biggest issue is with recycling resources. That needs to be done as part of this implementation. That flows through to the migrations which need to be reworked. There's a bunch to talk about with migrations that we can all go through as a group.

I moved "Resource recycling" from Non-Goals to Goal 4: "Full resource recycling — Reclaim IPs and IDs on deletion (users connect/disconnect frequently)". It's now mandatory.

[elitegreg]

I think this is close. Probably want to make some changes as we implement. I think in the migration phase, there's a stage where we run the activator still, but the existing activation instructions are updated to do resource allocation on exchange and ignores the passed in arguments. This supports the case where a user connects with an old client and needs async activation, but we want the activator and the new create-and-activate instructions to be in sync.

[elitegreg]

@vihu, why update existing accounts to add resource allocation? I would think we would just add new accounts with PDAs based on what they are associated with, e.g. create a dz prefix account with a pda based on the device key

[elitegreg]

@vihu, why update existing accounts to add resource allocation? I would think we would just add new accounts with PDAs based on what they are associated with, e.g. create a dz prefix account with a pda based on the device key

Also @juan-malbeclabs do you have an opinion

[juan-malbeclabs]

I agree with extending these functionalities into a second account associated with the first one to reduce the changes to the information that’s already on-chain.

PDA(Device Pubkey) or PDA(1111...1111)

You can create a resource extension account associated with the Device’s Pubkey and Pubkey::default() for the global state.
That account can manage resource allocation for both IDs and IPs. You’d have one or more ID bitmaps, plus an array of IP blocks with their own bitmaps.

Then we can add commands to allocate and release resources from these accounts, which could be used by the foundation manually or by the program internally.

[vihu]

I agree with extending these functionalities into a second account associated with the first one to reduce the changes to the information that’s already on-chain.

PDA(Device Pubkey) or PDA(1111...1111)

You can create a resource extension account associated with the Device’s Pubkey and Pubkey::default() for the global state. That account can manage resource allocation for both IDs and IPs. You’d have one or more ID bitmaps, plus an array of IP blocks with their own bitmaps.

Then we can add commands to allocate and release resources from these accounts, which could be used by the foundation manually or by the program internally.

Nice, I took another pass. Please take another look!

[elitegreg]

I don't think adding the slot fields to User, Link, etc are necessary. It's redundant information. The code I already have written can deallocate based on IP without knowing the slot.

Also, IMHO, this is close enough to go on with some implementation. Then we can update this. I think there is some amount of discovery that's necessarily going to happen and we don't want to over engineer upfront.

[nikw9944]

If TX 1 succeeds but TX 2 does not, does TX 1 get rolled back?