cosmos-sdk/x/capability
Amaury b49f948b36
feat: Add proto annotations for Amino JSON (#13501)
* add legacy_amino_name

* make-proto-gen

* remove useless omitempty

* add annotations

* Add proto annotations

* Add more annotations

* update cosmos-proto

* Add message scalar?

* Add comments

* Fix comment

* lint proto files

* proto-gen

* go mod tidy

* Add multisig encoding

* Add field name

* Format proto

* proto-gen

* Update proto/cosmos/msg/v1/msg.proto

Co-authored-by: Aaron Craelius <aaron@regen.network>

* Add dont_omitempty whenever we have nullable=false

* proto-gen

* Remove problematic annotations

* put legacy_amino in subpackage

* proto-gen

* Fixes

* legacy_amino.v1

* add non-working proto

* Generate in separate package

* Remove `cosmos.msg` prefix

* make proto-gen

* remove v1 too

* make proto-format

* Add field option

* format

* proto-gen

* Use underscores

* update legacy_amino -> amino

* update to `key_field`

* make proto-format

* make proto-gen

Co-authored-by: Aaron Craelius <aaron@regen.network>
2022-11-07 22:51:51 +00:00
..
keeper refactor: use mocks for x/capability testing (#12553) 2022-07-13 19:04:17 +00:00
simulation refactor: rename depinject imports to cosmossdk.io/depinject (#12479) 2022-07-09 17:46:07 +02:00
testutil feat!: consensus module (#12905) 2022-10-05 18:06:24 +00:00
types feat: Add proto annotations for Amino JSON (#13501) 2022-11-07 22:51:51 +00:00
capability_test.go refactor: remove simapp references from x/bank and x/slashing tests (#12897) 2022-08-11 16:23:45 +00:00
genesis_test.go feat: decouple x/capability from simapp (#12256) 2022-06-17 00:47:38 +02:00
genesis.go fix!: Capability Issue on Restart, Backport to v0.43 (#9836) 2021-08-03 18:50:08 +00:00
module.go feat: add autocli app wiring + remote info support (#13281) 2022-11-01 21:34:59 +00:00
README.md docs: fix toc links (#13770) 2022-11-04 15:35:22 +00:00

sidebar_position
1

x/capability

Overview

x/capability is an implementation of a Cosmos SDK module, per ADR 003, that allows for provisioning, tracking, and authenticating multi-owner capabilities at runtime.

The keeper maintains two states: persistent and ephemeral in-memory. The persistent store maintains a globally unique auto-incrementing index and a mapping from capability index to a set of capability owners that are defined as a module and capability name tuple. The in-memory ephemeral state keeps track of the actual capabilities, represented as addresses in local memory, with both forward and reverse indexes. The forward index maps module name and capability tuples to the capability name. The reverse index maps between the module and capability name and the capability itself.

The keeper allows the creation of "scoped" sub-keepers which are tied to a particular module by name. Scoped keepers must be created at application initialization and passed to modules, which can then use them to claim capabilities they receive and retrieve capabilities which they own by name, in addition to creating new capabilities & authenticating capabilities passed by other modules. A scoped keeper cannot escape its scope, so a module cannot interfere with or inspect capabilities owned by other modules.

The keeper provides no other core functionality that can be found in other modules like queriers, REST and CLI handlers, and genesis state.

Initialization

During application initialization, the keeper must be instantiated with a persistent store key and an in-memory store key.

type App struct {
  // ...

  capabilityKeeper *capability.Keeper
}

func NewApp(...) *App {
  // ...

  app.capabilityKeeper = capability.NewKeeper(codec, persistentStoreKey, memStoreKey)
}

After the keeper is created, it can be used to create scoped sub-keepers which are passed to other modules that can create, authenticate, and claim capabilities. After all the necessary scoped keepers are created and the state is loaded, the main capability keeper must be sealed to prevent further scoped keepers from being created.

func NewApp(...) *App {
  // ...

  // Creating a scoped keeper
  scopedIBCKeeper := app.CapabilityKeeper.ScopeToModule(ibchost.ModuleName)

  // Seal the capability keeper to prevent any further modules from creating scoped
  // sub-keepers.
  app.capabilityKeeper.Seal()

  return app
}

Contents

Concepts

Capabilities

Capabilities are multi-owner. A scoped keeper can create a capability via NewCapability which creates a new unique, unforgeable object-capability reference. The newly created capability is automatically persisted; the calling module need not call ClaimCapability. Calling NewCapability will create the capability with the calling module and name as a tuple to be treated the capabilities first owner.

Capabilities can be claimed by other modules which add them as owners. ClaimCapability allows a module to claim a capability key which it has received from another module so that future GetCapability calls will succeed. ClaimCapability MUST be called if a module which receives a capability wishes to access it by name in the future. Again, capabilities are multi-owner, so if multiple modules have a single Capability reference, they will all own it. If a module receives a capability from another module but does not call ClaimCapability, it may use it in the executing transaction but will not be able to access it afterwards.

AuthenticateCapability can be called by any module to check that a capability does in fact correspond to a particular name (the name can be un-trusted user input) with which the calling module previously associated it.

GetCapability allows a module to fetch a capability which it has previously claimed by name. The module is not allowed to retrieve capabilities which it does not own.

Stores

  • MemStore
  • KeyStore

State

In persisted KV store

  1. Global unique capability index
  2. Capability owners

Indexes:

  • Unique index: []byte("index") -> []byte(currentGlobalIndex)
  • Capability Index: []byte("capability_index") | []byte(index) -> ProtocolBuffer(CapabilityOwners)

In-memory KV store

  1. Initialized flag
  2. Mapping between the module and capability tuple and the capability name
  3. Mapping between the module and capability name and its index

Indexes:

  • Initialized flag: []byte("mem_initialized")
  • RevCapabilityKey: []byte(moduleName + "/rev/" + capabilityName) -> []byte(index)
  • FwdCapabilityKey: []byte(moduleName + "/fwd/" + capabilityPointerAddress) -> []byte(capabilityName)