Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What is the correct Policy? #510

Open
n0price opened this issue Nov 5, 2024 · 10 comments
Open

What is the correct Policy? #510

n0price opened this issue Nov 5, 2024 · 10 comments

Comments

@n0price
Copy link

n0price commented Nov 5, 2024

Dear Signatory Team,
I appreciate your help to share the correct policy to allow backer duties, voting, delegating, staking and unstaking and block transaction (ie: draining funds from consensus key). Thank you!

@michaelkernaghan
Copy link
Contributor

michaelkernaghan commented Nov 5, 2024

The format in your signatory.yaml file would be

 block:
      preattestation:
      attestation:
      generic:
        - transaction
        - reveal
        - delegation

You can choose from the policy list for the rest:
[activate_account, attestation, attestation_with_dal, ballot, dal_publish_commitment, delegation, double_attestation_evidence, double_baking_evidence, double_preattestation_evidence, drain_delegate, failing_noop, finalize_unstake, increase_paid_storage, origination, preattestation, proposals, register_global_constant, reveal, seed_nonce_revelation, set_delegate_parameters, set_deposits_limit, signature_prefix, smart_rollup_add_messages, smart_rollup_cement, smart_rollup_execute_outbox_message,
smart_rollup_originate, smart_rollup_publish, smart_rollup_recover_bond, smart_rollup_refute, smart_rollup_timeout, stake,
transaction, transfer_ticket, unstake, update_consensus_key, vdf_revelation, zk_rollup_origination, zk_rollup_publish,
zk_rollup_update]

So you might choose:

 block:
      preattestation:
      attestation:
      unstake:
      finalize_unstake:    
      generic:
        - transaction
        - reveal
        - delegation
        - drain_delegate

@n0price
Copy link
Author

n0price commented Nov 6, 2024

Thanks, so something like this should work to allow baker duties, delegation and staking transactions only.

tezos:
  tz1ExamplePublicKeyHash:
    log_payloads: true
    allow:
      endorsement:
        - endorsement
        - preendorsement
      generic:
        - delegation
        - stake
        - unstake
        - ballot
        - reveal 
      block:
        - block
    deny:
      generic:
        - transaction   # Deny general transactions (e.g., Alice sending to Bob)
        - drain_delegate  # Specifically block draining of consensus key

@michaelkernaghan
Copy link
Contributor

signatory is "closed by default" so there is no 'deny' block.

also, if you have 'unstake' you might want 'finalize_unstake' as well.

Finally, note as well that endorsement is now attestation and preendorsement is now preattestation

@n0price
Copy link
Author

n0price commented Nov 7, 2024

Thanks, the following example now is it correct?

tezos:
  tz1ExamplePublicKeyHash:
    log_payloads: true
    allow:
      block:
      preattestation:
      attestation:
      unstake:
      finalize_unstake:    
      generic:
        - transaction
        - reveal
        - delegation
        - drain_delegate

@michaelkernaghan
Copy link
Contributor

That should work.

@n0price
Copy link
Author

n0price commented Nov 18, 2024

Thanks, Is the Ledger reliable to use? Specifically, can we store the backer signing key on the Ledger, and how does this usually work? Does the signer need to retrieve the signing key from the Ledger each time it performs backer duties?

@michaelkernaghan
Copy link
Contributor

michaelkernaghan commented Nov 18, 2024

The Ledger hardware wallet provides excellent security for storing the signing key required for baking. It isolates the private key within its secure element, ensuring it cannot be extracted or used outside the Ledger's controlled environment. Details of how it works are in the documentation: https://signatory.io/docs/bakers

@n0price
Copy link
Author

n0price commented Nov 18, 2024

Thanks, my point does the signer needs to be connected always to the ledger to be able to perform duties?
My understanding as well the same private key that needed for the consensus is the same that control the self bond.

@michaelkernaghan
Copy link
Contributor

michaelkernaghan commented Nov 18, 2024 via email

@n0price
Copy link
Author

n0price commented Nov 19, 2024

Thanks. from the documentation I can not understand how does the remote signer really needs to be configured in practice.
Do we need to have 2 vms, both with the signer installed? one vm has the configuration to connect to the vault to sign the transaction, plus the hook configuration to connect the policy vm the policy configuration.

So my understanding the setup should something like the following:

The signer vm :

# config root
policy_hook:
    address: host:port
    # List of authorized keys in Tezos Base58 format
    authorized_keys:
        - pub1
        - pub2
        # ...
   
vaults:
  azure:
    driver: azure
    config:
      vault:    

The policy vm config:

tezos:
  tz1ExamplePublicKeyHash:
    log_payloads: true
    allow:
      block:
      preattestation:
      attestation:
      unstake:
      finalize_unstake:    
      generic:
        - transaction
        - reveal
        - delegation
        - drain_delegate

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants