Validator stake pool boostrap for local sandbox

[bharath-123]

Hi all,

I am using the latest workspaces-rs version: workspaces =

{ git = "[[https://github.com/near/workspaces-rs|| https://github.com/near/workspaces-rs%7C] [https://github.com/near/workspaces-rs| https://github.com/near/workspaces-rs]]" }

I am trying to write contracts which will integrate with the validator stake pool contracts. With unstaking and rewards accrual taking an epoch, its not easy to test these contracts on testnet. The epoch forward feature in the local sandbox is very useful in such cases. it would be great if the sandbox can be bootstrapped with a validator stake pool too. That would make it very easy to test stake pool integrations.

Currently we would have to deploy a stake pool with a public key. I don't see a straightforward way to get the validator public key from the workspace-rs library. but i may be wrong. This process is very manual. Boostrapping it can make the dev experience nicer.

Since stake pools is a core part of the eco system, there will be a lot of integrations with this contract. i definitely see value in it.

[ChaoticTempest]

I see, thanks for bringing this up! I'll make the keys available for usage then. The credentials are already being exposed to the users to save as a file, but that's quite involved for users to grab just to send the bytes into a transaction.

Also, if I understand what you're saying about bootstrapping correctly, having the staking pool contract inside workspaces library itself would make it bloated right now. It's best if we have it at a higher level library to facilitate that, just so that workspaces-rs can focus purely on testing and automation. But definitely, this is good feedback that it would make it easier to plugin such libraries to test and play around with it later on

[bharath-123]

hey @ChaoticTempest Thanks for the quick turnover! I understand your concern about the bloat. But I also do feel that maybe boot strapping the sandbox with core contracts could be a good idea. Even if the user has to provide the wasm, some functionality to setup a stake pool contract and a complete validator would be really useful.

[ChaoticTempest]

hmm, well most of the functionality (after exposing the keys) should be available for users to make use of to deploy the staking contract. workspaces-rs is already running a node underneath and that will pretty much be your validator node. We just gotta deploy the staking contract and initialize it with our data. It'd look something like this if I'm understanding the staking contract correctly:

let worker = workspaces::sandbox().await?;

let owner = worker.root_account();
let pk = owner.secret_key().public_key();
let staking_contract = worker.dev_deploy("./path/to/staking-contract.wasm").await?;

owner.call(&worker, staking_contract.id(), "new")
    .args_json(json!({
         "owner_id": owner.id(),
         "stake_public_key": pk,
         ... 
    })?
    .transact()
    .await?;

Which looks pretty straightforward to me. I don't see what else workspaces could provide that would add more value. Is there something that would be useful here that I'm missing?

[bharath-123]

hey @ChaoticTempest thanks for replying. i just felt it would be nicer to bootstrap with the workspace because that would be closer to the mainnet and testnet. Since validator staking is an important part of defi and many protocols would integrate with your contract.

Since validator stake pool contracts are so essential to the eco system, having it already pre-setup in the sandbox where users can query the addresses would be super cool!

TLDR; By bootstrapping with validator stake pool contract, near sandbox would have more parity with testnet and mainnet is my opinion! :D

[ChaoticTempest]

near sandbox would have more parity with testnet and mainnet

I'm not sure I follow this parity part though. testnet and mainnet shouldn't have validator stake pools by default. Like, if you'd like to have your own stake pool, you'd have to deploy one yourself into testnet/mainnet.

I get that it would be nice to have, but there's some issues that gets added to workspaces that would be hard for most people to work with outside of DeFi. Like, the main issue with bootstrapping this will be the bloat: not all tests/workflows in workspaces will need this or are concerned with DeFi, so it just becomes wasted cycles. For people who want to test, this just ends up making their tests longer to load up (which scales linearly with the number of tests). We already have complaints about the current workspaces-rs being slower than the deprecated simulator counterpart. It's a non-starter in that case and plus, it's pretty trivial to just add all the setup on the user-side