Contract upgrade: Crabble

[anilhelvaci]

What is the Problem Being Solved?

As mentioned in #8158, we need the ability to restart or replace all vats. This issue is focused on upgrading Crabble.

Description of the Design

Crabble is designed to be upgradable from the get go. These swingSet tests demonstrate a comprehensive coverage of its features across upgrades.

During its launch we didn't implement functional tests for Crabble to run in a3p environment. To make sure the functionality stays consistent across upgrades, we need to implement those functional tests now.

End-to-end use cases depend on time as a variable

When writing tests where the behavior of the functionality (such as auctions) depends on time in a3p environment, things get tricky. https://github.com/Agoric/BytePitchPartnerEng/issues/35, https://github.com/Agoric/BytePitchPartnerEng/issues/36, https://github.com/Agoric/BytePitchPartnerEng/issues/39 and Agoric/agoric-3-proposals#179 talks about this in more depth.

A typical end-to-end scenario for Crabble looks like;

• NFT owner puts their asset into Crabble to be escrowed
• Another user borrows the NFT
• Borrower keeps the NFT for predetermined period of time
  • No early returns are permitted (enforced by the contract)
• Borrowing period ends, borrower has to return the NFT
• Borrower returns the NFT
• Gets their collateral back

What can we do instead?

In order to avoid depending on time, we can focus on functionality other than the returning the NFTs. In the PREPARE phase of n:upgrade-next;

• An owner puts three NFTs (NFT-1, NFT-2, NFT-3) into Crabble escrow with different renting tiers
• A borrower borrows NFT-1

In TEST phase (after upgrade);

• Observe the owner is able to change the rental configuration of NFT-2
• Observe the owner is able to withdraw NFT-3
• Observe the borrower still holds NFT-1 and Crabble knows it is on rent
• Observe the borrower is able to borrow NFT-2
• Observe the borrower holds NFT-2 and Crabble knows it is on rent

How much work is this?

I assume it's more then usual. As we need at least one faucet to serve as our source of NFTs. We could use validator account as our faucet for the fungible assets. The biggest factor here is that we have zero functional tests for Crabble in a3p.

Security Considerations

In terms user assets, playing around with Crabble is pretty safe even on Mainnet as there's zero active users. From the Agoric System standpoint Crabble doesn't cause any excess resource consumption or negatively effect other vats as per the inspections made in #8280 during the deployment.

Scaling Considerations

We don't expect Crabble to grow in any time soon.

Test Plan

Open Question: Should we test ability to pause offers after the upgrade?

This is something I assume we should do, but not so sure as we didn't plan to do it for Kread. Implementing this would increase the effort going into this ticker for sure.

Upgrade Considerations

Upgrade core-eval should go in upgrade.go.

[otoole-brendan]

@anilhelvaci to help determine how much testing we should do around this could you help by providing estimates to test:
a) ensure the upgrade works (bare minimum) and
b) all promised functionality
Understanding how much effort these are will help inform whether it's a good use of time - thanks!
cc @Chris-Hibbert

[anilhelvaci]

ensure the upgrade works (bare minimum)

I think we need to define what bare minimum is.

• Is it making sure crabble can be upgraded without getting terminated during new incarnation's boot?
• Is it to see crabble still holds its escrowed assets with the correct state after an upgrade?

Without some definition of a bare minimum it's impossible for me to give an estimation.

all promised functionality

4 to 5 working days I would say.

cc @otoole-brendan