[AT]: Replace the `issued_capabilities` list with a `revoked_capabilities` list based on `LinkedTable`

[itsyaasir]

Feature description

Currently the VecSet we are using for the issued_capabilities list is limited to 1000 objects, we should consider switching to a black list revoked_capabilities, based on a LinkedTable collection which uses dynamic fields and is fully scalable.

Every time a capability is validated, we need to retrieve the capability in a capability black- or white-list. The cost of the contains() function, offered by the used collection therefore has a strong impact on the processing gas cost.

Summary of the collection ananlysis below:

• A Black List (revoked_capabilities) will have smaller size
• LinkedTable offers the most advantages and only one drawback regarding needed storage gas
• A LinkedTable Black List revoked_capabilities would gather the most advantages for an MVP implementation
• Black- and White-lists can be reduced in size, using capability's valid_until constraint

Advantages and Drawbacks of list types

White List → issued_capabilities:

• grows with every issued capability → larger list size

Black List → revoked_capabilities:

• grows only when capabilities are revoked → smaller list size

If used in combination with the capability's valid_until constraint and utility functions for removal of expired capabilities, the sizes of both list types can be reduced.

Advantages and Drawbacks of collection types

Suitable collections need to provide the following functionality:

• Fast contains() function implementation
• Possibility to destroy() all entries before destroy_empty() of the collection is called, ideally without the need of an offchain RPC call
• remove() entry function

Additionally the needed onchain storage-size is important to keep the storage gas cost low.

Advantages (+) and disadvantages (-) of the collection types in detail

LinkedTable

• Offers all needed functions
• Fast contains() function, uses the native Move runtime function object_exists based on Rust BTreeMap → Scalable also for very big lists
• Is dynamic field based → can grow infinitely
• Can be realized with very little implementation cost

• Needs approximately 3 x storage size
• Uses a dynamic field per list entry → higher processing and storage gas cost due to dynamic field overhead

Table

• Offers 2 of 3 needed functions
• Fast contains() function, uses the native Move runtime function object_exists

• Needs an RPC call to destroy() all entries before destroy_empty() can be used → offchain product client function needed to prepare destroying the AT

• Is dynamic field based → can grow infinitely
• Needs only 1 x storage size

• Uses a dynamic field per list entry → higher processing and storage gas cost due to dynamic field overhead
• Higher implementation cost, due to needed offchain product client functionality

VecSet

• Offers 2 of 3 needed functions

• Slow contains() function, uses linear search → very inefficient for long lists → not scalable
• Limited growth: Size is limited due to max object size of 250KB (usually < 1000 entries) → list overflow risk for users

• Needs less than 1 x storage size
• Lower processing and storage gas cost due to not using dynamic fields

• Higher implementation cost, due to needed documentation regarding list overflow risks