package tezos-protocol-alpha

  1. Overview
  2. Docs
package tezos-protocol-alpha
Legend:
Library
Module
Module type
Parameter
Class
Class type
module Commitment_hash = Sc_rollup_commitment_repr.Hash
type point = {
  1. commitment : Sc_rollup_commitment_repr.t;
  2. hash : Commitment_hash.t;
}
type conflict_point = point * point

get_ongoing_games_for_staker ctxt rollup staker returns games, the list of refutation games currently played by staker in the rollup.

get_game ctxt rollup stakers returns the game between stakers.alice and stakers.bob.

type conflict = {
  1. other : Sc_rollup_repr.Staker.t;
  2. their_commitment : Sc_rollup_commitment_repr.t;
  3. our_commitment : Sc_rollup_commitment_repr.t;
  4. parent_commitment : Sc_rollup_commitment_repr.Hash.t;
}

A conflict between a staker and an other staker. The conflict is about the commitment that follows the parent_commitment: their_commitment and our_commitment are distinct, hence in conflict.

conflicting_stakers_uncarbonated rollup staker returns the list of conflicts with staker in rollup.

Notice that this operation can be expensive as it is proportional to the number of stakers multiplied by the number of commitments in the staked branches. Fortunately, this operation is only useful as an RPC for the rollup node to look for a new conflict to solve.

start_game ctxt rollup ~player:(player, player_commitment_hash) ~opponent:(opponent, opponent_commitment_hash) initiates a refutation game between player and opponent in the given rollup as they are in conflict with commitment and opponent_commitment. Where commitment is the commitment in the storage with hash player_commitment_hash (resp. opponent_commitment with opponent_commitment_hash).

game_move ctxt rollup player opponent refutation handles the storage-side logic for when one of the players makes a move in the game. It checks the game already exists. Then it checks that player is the player whose turn it is; if so, it applies refutation using the play function.

If the result is a new game, this is stored and the timeout is updated.

May fail with:

  • Sc_rollup_does_not_exist if rollup does not exist
  • Sc_rollup_no_game if is_opening_move is false but the game does not exist
  • Sc_rollup_game_already_started if is_opening_move is true but the game already exists
  • Sc_rollup_no_conflict if player is staked on an ancestor of the commitment staked on by opponent, or vice versa
  • Sc_rollup_not_staked if one of the player or opponent is not actually staked
  • Sc_rollup_staker_in_game if one of the player or opponent is already playing a game
  • Sc_rollup_wrong_turn if a player is trying to move out of turn

The is_opening_move argument is included here to make sure that an operation intended to start a refutation game is never mistaken for an operation to play the second move of the game---this may otherwise happen due to non-deterministic ordering of L1 operations. With the is_opening_move parameter, the worst case is that the operation simply fails. Without it, the operation would be mistaken for an invalid move in the game and the staker would lose their stake!

timeout ctxt rollup stakers checks that the timeout has elapsed and if this function returns a game result that punishes whichever of stakers is supposed to have played a move.

The timeout period is defined a protocol constant, see Constants_storage.sc_rollup_timeout_period_in_blocks.

May fail with:

  • Sc_rollup_no_game if the game does not in fact exist
  • Sc_rollup_timeout_level_not_reached if the player still has time in which to play

Note: this function takes the two stakers as a pair rather than separate arguments. This reflects the fact that for this function the two players are symmetric. This function will normalize the order of the players if necessary to get a valid game index, so the argument stakers doesn't have to be in normal form.

get_timeout ctxt rollup stakers returns the current timeout values of both players.

apply_game_result ctxt rollup game_result takes a game_result produced by timeout or game_move and performs the necessary end-of-game cleanup: remove the game itself from the store and punish the losing player by removing their stake. In the case where the game ended in a draw, both players are slashed.

This is mostly just calling remove_staker, so it can fail with the same errors as that. However, if it is called on an game_result generated by game_move or timeout it should not fail.

Note: this function takes the two stakers as a pair rather than separate arguments. This reflects the fact that for this function the two players are symmetric. This function will normalize the order of the players if necessary to get a valid game index, so the argument stakers doesn't have to be in normal form.

Removes pending refutation games in the context where the players are no longer staked.

OCaml

Innovation. Community. Security.

GitHub Discord Twitter Peertube RSS
About
Changelog Releases Industrial Users Academic Users Why OCaml
Ecosystem
Packages Community Events OCaml Planet Jobs
Resources
Install OCaml Get Started Platform Tools Language Manual Standard Library API Books Exercises Papers OCaml Playground Logo
Policies
Carbon Footprint Governance Privacy Code of Conduct