TzSafe and Proof of Event with demos

Research and Development
1

The Marigold Dapps team is aligning with the Tezos standard to facilitate integration and maintain uniformity.

TzSafe and Proof of Event

TzSafe, a multisig wallet, integrated TZIP-27 to adhere to Tezos’ account abstraction specification. An implicit account represents an identity that a user employs a private key to prove authorization, resulting in a signature. Conversely, an originated account cannot achieve the same, as it lacks a private key. Furthermore, the authorization and execution of an implicit account are intertwined. TZIP-27 introduces a standard to demonstrate the authorization of an originated account by offering proof of event (PoE), an alternative to message signing.

How TzSafe works

A TzSafe wallet, also referred to as a TzSafe contract and abbreviated as TzSafe, is an originated account that operates as a multisig wallet, utilizing on-chain signatures for authentication. The owners of the multisig wallet share its ownership, and the identity of TzSafe embodies the consensus among these owners. Transactions approved through the owners’ consensus are referred to as “actions” to differentiate the term from Tezos’ standard transactions. An action could encompass activities such as transferring 5 XTZ to Alice or executing Bob’s smart contract.

Executing an action on TzSafe involves three steps:

  1. Create a proposal: Whenever owners intend to execute an action on TzSafe, one of them must generate an on-chain proposal with the TzSafe contract.
  2. Sign the proposal: Owners can indicate their approval or disapproval of the proposal by providing their on-chain consent.
  3. Resolve the proposal: After gathering a satisfactory number of approvals, one of owners can execute the action on behalf of the entire group by resolving the proposal.

Let’s take a look at an example of a 2-of-3 multisig wallet within TzSafe. This scenario involves three owners: Alice, Bob, and Charlie. To execute an action, a minimum of 2 approvals from the owners is required.

Now, let’s assume Alice aims to transfer 5 XTZ to Daisy using TzSafe. Initially, she creates a proposal for the intended action. Subsequently, Bob expresses agreement with the proposal and adds his approval by signing it. After Bob’s signing, Alice signs the proposal as well. Upon discovering that two approvals have already been obtained and no further endorsement from Charlie is necessary, Alice concludes that the proposal is resolvable. Consequently, she resolves the proposal, enabling the execution of the action. As a result, Daisy receives 5 XTZ from the TzSafe.

Proof of Event on TzSafe

This section describes three proposed models for integrating with PoE. Each model offers a distinct interpretation of PoE, functioning as signatures. The upcoming subsections utilize the TzSafe example mentioned earlier to illustrate the implementation of PoE with TzSafe. In the following diagrams, two additional components are introduced: DApp and TzSafe App. The term “DApp” encompasses entities like Batcher and objkt.com. The “TzSafe App” is a wallet application designed to facilitate communication between the DApp and deployed TzSafe contracts, streamlining operations for the owner’s convenience.

PoE as an executed action

If we consider the identity of TzSafe to be the same as that of an implicit account, only the actions taken by TzSafe hold significance for the owners or the DApp. Other Tezos transactions, like creating or signing a proposal, are regarded as internal transactions of TzSafe, which are inconsequential to the owners and particularly the DApp. In most cases, the DApp wouldn’t respond to an action that hasn’t occurred. Hence, to emulate the behavior of an implicit account, the PoE, symbolizing a signature, needs to be linked to an action performed by TzSafe. In essence, TzSafe implements the proof of event challenge on TZIP-27 through the process of resolving the proposal. When the result of resolving the proposal is the execution of an action, the PoE should be emitted by the TzSafe, as shown in the following sequence diagram.

In the example above, Alice initially utilizes the DApp to establish a connection with the TzSafe App. Subsequently, Alice creates a proposal, including an action, within TzSafe. Each proposal created within TzSafe receives a unique proposal ID. This proposal ID aligns with the challenge ID described in TZIP-27, while the action contained within the proposal serves as the payload as stipulated by TZIP-27. Following that, the Dapp initiates a request for the proof of event challenge, which mirrors the process outlined in TZIP-27 and is illustrated in the sequent diagram below. When the proposal gains two approvals and is resolved, the proof of event challenge will be proceeded, leading to the emission of PoE. Ultimately, the Dapp can access and verify the PoE on-chain.

Here is a demo:

The PoE as an agreement

One of the core principles of account abstraction is to disentangle authorization from execution, thereby enabling contracts to tailor their own authorization logic. Presently, the originated account structure in Tezos, however, doesn’t provide the same level of customization as seen in Ethereum’s EIP-4337 and EIP-2938, the proposals for account abstraction on Ethereum. Nevertheless, there exists an approach for DApps to observe the outcome of authorization with PoE, allowing them to make decisions. When incorporating TzSafe within this context, authorization should occur once the proposal gains the minimum required approvals. Consequently, the PoE becomes observable when an owner, whose approval fulfills the minimum requirement, signs the proposal. This is illustrated in the subsequent diagram.

The example above is similar to the previous one. The difference is that the proof of event challenge takes place when signing the proposal.

Here is a demo:

PoE as authorization of proposing action

If we interpret the PoE as the authorization for proposing an action, it signifies that the DApp will recognize the forthcoming proposal. Consequently, the DApp can monitor the ongoing transactions of the proposal. However, this form of authorization functions more akin to that of an individual owner, rather than representing the collective consensus of the owners.

Here is a demo:

Conclusion

PoE represents a signature and stands the outcome of authorization. Users are at liberty to interpret the signature’s significance. In this post, we outline three methods for integration with TzSafe. A comparison of these approaches is provided below, and each approach offers a distinct user experience to DApps.

Aspect Model 1 Model 2 Model 3
PoE as an executed action an agreement authorization of proposing action
Triggered when resolve a proposal when sign a proposal before create a proposal
Identify the consensus of owners the consensus of owners individual owner

Other

8 Likes