origami World Marionette

World admins have unlimited authority in to modify the world, including setting arbitrary state, upgrading contracts, etc. This is a useful functionality in the early days of the worlds deployment but can be a liability in certain cases. Currently, it is only possible to have unlimited power or none at all. This issue is to create a proxy contract that would take ownership of a world, enabling progressive decentralization of world administration over time.

The basic idea is to wrap the permissioned endpoints in a proxy contract that will be the world admin. The Marionette contract should support the ability to gate calls to these endpoints based on an exception list.

For example, in the case of set_entity, the owner of the Marionette contract can set model exceptions that will prevent the world admin from writing directly to those models. For example, if the world had a erc20 token deployed to it, it could add the erc20 balance model as an exemption which would prevent the admin from modifying that state. The same should be possible for preventing upgrades of particular contracts by the admin.

This will enable world admins to progressively decentralize the operation of the world by selectively making different resources immutable.

An additional feature that could be useful, is to support timelocks for exceptions, so the admin could be able to upgrade and erc20 contract implementation but could be subject to a t day timelock.

The permissioned endpoints to proxy:

    fn set_entity(
        ref self: T,
        model: felt252,
        keys: Span<felt252>,
        offset: u8,
        values: Span<felt252>,
        layout: Span<u8>
    );
    fn delete_entity(ref self: T, model: felt252, keys: Span<felt252>, layout: Span<u8>);
    fn upgrade_contract(ref self: T, address: ContractAddress, class_hash: ClassHash) -> ClassHash;
    fn set_executor(ref self: T, contract_address: ContractAddress);
    fn upgrade(ref self: T, new_class_hash: ClassHash);
    fn grant_owner(ref self: T, address: ContractAddress, resource: felt252);
    fn revoke_owner(ref self: T, address: ContractAddress, resource: felt252);
    fn grant_writer(ref self: T, model: felt252, contract: ContractAddress);
    fn revoke_writer(ref self: T, model: felt252, contract: ContractAddress);

Addition interfaces:

OwnableTwoStep https://github.com/OpenZeppelin/cairo-contracts/blob/44b5259ca316c4a7931e8ca77699bb3c00c70a54/src/access/ownable/interface.cairo#L20

#[starknet::interface]
trait IMarionetteFreeze<TState> {
    fn freeze(ref self: TState, resource: felt252, timelock: felt252);
}

In the token example, if the model is erc20_balance and the contract is erc20, to make the contract immutable, the admin would call freeze on the model and contract resources. Then any permissioned endpoints that interact with models / contracts will assert the exemption criteria before proxying the call to the underlying world.

Feb 16 '24 14:02 tarrencev

will love to work on this can i be assign this task

May 05 '24 11:05 ebukizy1

@tarrencev Can I work on this?

Jun 26 '24 15:06 PedroRosalba

I am applying to this issue via OnlyDust platform.

My background and how it can be leveraged

I'm a blockchain developer. i will love to work on this

Sep 25 '24 19:09 CollinsC1O

I am applying to this issue via OnlyDust platform.

My background and how it can be leveraged

I am a blockchain developer with experience in both Solidity and Cairo. I have worked on smart contract development and upgradeable proxy patterns in Ethereum, and I'm familiar with StarkNet's contract architecture. My experience with implementing access control mechanisms and timelocks in smart contracts will be particularly relevant to this task. I've also contributed to open-source projects in the past, which has honed my ability to write clean, well-documented code that integrates smoothly with existing codebases.

How I plan on tackling this issue

To address this enhancement, I would start by thoroughly reviewing the current World contract implementation and the proposed Marionette proxy contract requirements. My approach would involve the following steps: First, I would design the Marionette contract architecture, ensuring it can effectively proxy all the specified permissioned endpoints while maintaining the ability to selectively restrict access based on exceptions. I would implement a robust exception management system, allowing for both model-based and contract-based exceptions. Next, I would develop the core proxy functionality, carefully handling the delegation of calls to the underlying World contract. This would include implementing checks against the exception list before proxying each call. For the timelock feature, I would design a system that can queue proposed changes and execute them after a specified delay, drawing inspiration from established timelock patterns in the Ethereum ecosystem. I would then implement the IMarionetteFreeze interface, ensuring that the freeze function correctly adds resources to the exception list and respects the specified timelock. This would involve creating a data structure to store frozen resources and their associated timelocks. Throughout the development process, I would write comprehensive unit tests to verify the correct behavior of each component, including edge cases and potential attack vectors. I would also conduct integration tests to ensure the Marionette contract interacts correctly with a mock World contract.