{"id":30824065,"url":"https://github.com/imdea-software/leanfraudproofs","last_synced_at":"2025-09-06T11:12:29.445Z","repository":{"id":311273645,"uuid":"1043206342","full_name":"imdea-software/LeanFraudProofs","owner":"imdea-software","description":"L2 Optimistic rollups fraud proofs mechanization","archived":false,"fork":false,"pushed_at":"2025-08-23T12:31:59.000Z","size":12306,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":0,"default_branch":"main","last_synced_at":"2025-08-23T18:49:43.288Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"JavaScript","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/imdea-software.png","metadata":{"files":{"readme":"README.org","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null}},"created_at":"2025-08-23T11:09:07.000Z","updated_at":"2025-08-23T12:30:17.000Z","dependencies_parsed_at":"2025-08-23T18:59:48.483Z","dependency_job_id":null,"html_url":"https://github.com/imdea-software/LeanFraudProofs","commit_stats":null,"previous_names":["imdea-software/leanfraudproofs"],"tags_count":2,"template":false,"template_full_name":null,"purl":"pkg:github/imdea-software/LeanFraudProofs","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/imdea-software%2FLeanFraudProofs","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/imdea-software%2FLeanFraudProofs/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/imdea-software%2FLeanFraudProofs/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/imdea-software%2FLeanFraudProofs/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/imdea-software","download_url":"https://codeload.github.com/imdea-software/LeanFraudProofs/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/imdea-software%2FLeanFraudProofs/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":273893299,"owners_count":25186622,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","status":"online","status_checked_at":"2025-09-06T02:00:13.247Z","response_time":2576,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2025-09-06T11:12:13.883Z","updated_at":"2025-09-06T11:12:29.399Z","avatar_url":"https://github.com/imdea-software.png","language":"JavaScript","funding_links":[],"categories":[],"sub_categories":[],"readme":"* [[https://imdea-software.github.io/LeanFraudProofs/][Clickable Documentation]]\n* CCS'25\nMain artifact proofs are in [[./FraudProof/L2.lean][L2]] .\n\nZenode badge:\n\n[[https://doi.org/10.5281/zenodo.16993258][https://zenodo.org/badge/1043206342.svg]]\n\n\n** Main proof is ~honest_chooser_valid~ proving our main validity claim.\n#+begin_src lean4\ntheorem honest_chooser_valid {α ℍ}\n   [BEq ℍ][LawfulBEq ℍ][DecidableEq α]\n   [o : Hash α ℍ][m : HashMagma ℍ][InjectiveHash α ℍ][InjectiveMagma ℍ]\n   (val_fun : α -\u003e Bool)\n   (p1 : P1_Actions α ℍ)\n   : linear_l2_protocol val_fun p1 ( fun (t, mt) =\u003e honest_chooser val_fun t mt)\n     ↔ local_valid p1.da val_fun\n#+end_src\n\n** Players\n*** Player One, proposing DAs, is defined as a new batch with all possible moves in all possible games.\n#+begin_src lean4\nstructure P1_Actions (α ℍ : Type) : Type\n where\n da : BTree α × ℍ\n dac_str : ABTree (Option α) (Option (ℍ × ℍ))\n gen_elem_str : {n : Nat} -\u003e ISkeleton n -\u003e (Sequence n (Option (ℍ × ℍ)) × Option α)\n#+end_src\n*** Player Two, the one (possibly) challenging, is defined as\n#+begin_src lean4\ninductive P2_Actions (α ℍ : Type)  : Type\n  where\n   | DAC (str : ABTree Unit ((ℍ × ℍ × ℍ) -\u003e Option ChooserMoves))\n   | Invalid {n : Nat} (p : α) (seq : ISkeleton n) (str : Sequence n ((ℍ × ℍ × ℍ) -\u003e Option ChooserSmp))\n   | Duplicate (n m : Nat)\n      -- There are two paths\n      (path_p : ISkeleton n) (path_q : ISkeleton m)\n      -- Strategies to force proposer to show elements.\n      (str_p : Sequence n ((ℍ × ℍ × ℍ) -\u003e Option ChooserSmp))\n      (str_q : Sequence m ((ℍ × ℍ × ℍ) -\u003e Option ChooserSmp))\n   | Ok\n#+end_src\n** Validity of Batches.\nNotion of (local) batch validity is defined exactly as the article says:\n#+begin_src lean4\ndef local_valid {α ℍ : Type} [DecidableEq α][Hash α ℍ][HashMagma ℍ]\n  (da : BTree α × ℍ)(val_fun : α -\u003e Bool) : Prop\n -- Merkle Tree is correct\n := da.fst.hash_BTree = da.snd\n -- All elements are |val_fun| valid\n ∧ (da.fst.fold val_fun and)\n -- There are no duplicated elements.\n ∧ List.Nodup da.fst.toList\n#+end_src\n** Winning Lemmas\nTo see how we prove that honest players win games see file [[./FraudProof/Games/ElementInTree.lean][ElementInTree]] .\n+ Lemma ~elem_back_rev_honest_two~ stating that knowing the data, honest\n  choosers lead proposers either to quit or to prove that an element is in a\n  tree.\n+ We define the notion of winning conditions in file [[file:./FraudProof/Game/GenericTree.lean][GenericTree]] and prove that\n  proposers win ~winning_proposer_wins~.\n** Adding History.\nTo complete the CSS'25 article proofs, we needed to check that there are no\nduplicates elements across history.\nLocal validity is local to each block, but history non-duplicity is contextual\nand depends on the previous elements added. It is effectful in a way.\n\nWe defined a new protocol in [[./FraudProof/History_L2.lean][History L2]] on top of the previous one ( [[./FraudProof/L2.lean][L2]] ).\nThe new protocol has a history of added blocks and checks that all blocks are\nlocal valid plus they do not duplicate elements.\n#+begin_src lean4 :noeval\ndef historical_valid\n  {α ℍ : Type} [DecidableEq α][Hash α ℍ][HashMagma ℍ]\n  -- History of commited blocks and their hashes.\n  (Hist : List (BTree α × ℍ))\n  -- Validity Function\n  (val_fun : α -\u003e Bool)\n  : Prop\n  :=\n  -- Each epoch is `local_valid`\n  (∀ e ∈ Hist, local_valid e val_fun)\n  ∧ -- Plus there are no duplicated elements. This one subsumes nodup in local_valid.\n  (List.Nodup (Hist.map (BTree.toList $ ·.fst)).flatten)\n#+end_src\n\nWe add a new move for player two, now the player two (the chooser) can detect\nduplicate elements across history and build witnesses and fraudproofs\naccordingly.\nPlayer one (the proposer), now has to provide strategies defending their claim\nfor all elements across history too. Since we do not have IO.\n\nSame as before, our main theorem is that the protocol equipped with an honest\nplayer only accepts valid blocks.\n\n#+begin_src lean4 :noeval\ntheorem HistoryProtocol {α ℍ}\n   [BEq ℍ][LawfulBEq ℍ][DecidableEq α]\n   [o : Hash α ℍ][m : HashMagma ℍ][InjectiveHash α ℍ][InjectiveMagma ℍ]\n   (val_fun : α -\u003e Bool)\n   (p1 : P1_History_Actions α ℍ)\n   --\n   (hist : List (BTree α × ℍ))\n\n   : (linear_l2_historical_protocol val_fun hist p1\n        (fun h (t, mt) =\u003e historical_honest_algorith val_fun h t mt)\n    ∧\n      historical_valid hist val_fun)\n   ↔ historical_valid (hist ++ [p1.local_str.da]) val_fun\n#+end_src\n* Compilation\n\n** Lake Compilation (Lean native)\nGet lean first, https://leanprover-community.github.io/get_started.html .\n\nTo build the whole project should suffice with a simple lake build command\n#+begin_src bash\nlake update\nlake build\n#+end_src\n\nFollow Makefile:\n#+begin_src bash\nmake help\n#+end_src\n** Nix Compilation\n\nGet Nix, follow make file.\n\n#+begin_src bash\nmake help\n#+end_src\n\n** Compile Documentation\nSee Makefile help.\n\n** Added Pages\n\n\n* Project Structure:\n** Data Structures\nHere I programmed useful data structures:\n+ BTree :: Binary Trees\n+ Hash ::  Hash stuff, classes defining hash function from one type to another.\n  Collision Free notions.\n+ MTree :: Merkle Trees. (BTree + Hashes).\n+ Sequences :: Fin lists (Sequences,Arrays?,n-Tuples), in Lean\n #+begin_src lean4 :noeval\ndef Sequence (a : Type) (n : Nat) := { t : List a // t.lenght = n }\n #+end_src\n+ SeqBTree :: Sequences to BTrees. Balance Complete Trees, so we can show log\n  search of fraud-proofs.\n+ TreeAccess :: Main star when formalizing L2 (Arranger) games. Main lesson\n  here, we need to characterize the algorithm in a complete way. We need errors\n  and enough information to build fraudproofs. This reminds me a lot of 'Z'\n  charts characterizing good and bad behaviours.\n\n  - Find invalid elements returning extra metadata when an invalid element is\n    found and proof-carrying data when no element is found. We need extra data\n    to build strategies and to eventually prove that correct agents always win.\n  - Find duplicated elements. Find_inv ; Find_inv when invalid is membership?\n    Several proofs are needed here.\n\n** Extras\nDon't really remember here, files here may be obsolete.\n** Games\n+ ElemInTree :: Arbitration games proving element membership in merkle trees.\n+ FMBC :: Fmbc stuff. I did it to guide reviewrs, idk.\n+ FromBtoMTree :: DAC game, merkle tree is correctly built arbitration game.\n+ GameDef :: definitions of games.\n+ GenericTree :: Generic Games played on top of Binary Trees arenas.\n+ LogProof :: logarithmic games are logarithmic.\n+ PathToTreeGames :: similar to ElemInTree?\n+ ReverseLinearGames :: linear games can be played bottom-up ant top-down.\n+ Simultaneous :: Arbitration Games where both players provide their strategies\n  before playing. It is not their complete strategies but a commitment element.\n  The Merkle Tree root of their strategies.\n** Proofs\nAgain, not so sure.\n** L2.Lean\nRoot file implementing Arranger games and strategies.\nUsing everything we defined, we prove that honest players always win.\n** HistoryL2.Lean\nRoot file implementing Arrangers with History.\nUsing everything we defined, we prove that honest players always win and\nthey accept honest claims.\n* FraudProof\n\nHere we aim to implement and formalize FraudProof ideas placed in L2 Setchain.\n\n** Implementation List\n*** DONE Basic Data Structures\n**** DONE [[file:FraudProof/DataStructures/BTree.lean][Binary Tree]]\nSmall binary tree implementation plus some important definitions:\n\nSibilings path from an element to /the root/.\n#+begin_src lean :noeval\nabbrev TreePath (α : Type ):= List (Sum (BTree α) (BTree α))\n#+end_src\n\nWhen an element is in a tree, and moreover, we can compute its proof. In this\ncase, a path from the element (value) to the root.\n\n#+begin_src lean :noeval\ndef valueIn [BEq α] (v : α) ( bt : BTree α ) : Bool\ndef valueInProof [BEq α](v : α) (bt : BTree α) : Option ( TreePath α )\n#+end_src\n\n**** DONE [[file:FraudProof/DataStructures/Value.lean][Value]]\nOpaque type representing values in our data structure.\n\nRequisites: an equilvalence relation.\n**** DONE [[file:FraudProof/DataStructures/Hash.lean][ Hash]]\nHash are strings (maybe we can change that, there is a hash notion already in Lean)\n\nIt defines a hash function ~H : Value -\u003e Hash~ and an operator ~\\oplus: Hash -\u003e Hash -\u003e Hash~.\n\nMoreover, we assume perfect hashing (no collisions).\n#+begin_src lean :noeval\naxiom hash_prop (v1 v2 : Value) : v1 ≠ v2 → H v1 ≠ H v2\n#+end_src\n**** DONE Merkle Tree simple data structure [[file:FraudProof/MTree.lean][MTree Implementation]]\nMerkle Trees are nothing but the hash of the root of the markle tree they\nrepresent.\n\nHere we define important notions as hash paths. For example, a Hash is in a\nMerkle tree, if we provide the /evidence/, a list of hashes and positions,\nleading to the root.\n\n#+begin_src  lean :noeval\ndef nodeIn (h : Hash) (path : Path) (t : MTree) : Bool\n:= match t with\n| MTree.node hT =\u003e listPathHashes h path == hT\n\n#+end_src\n*** DONE Games data structures\n**** DONE Games\nThere is only one game: membership game.\nGiven a value (or a hash), it is an element in a given Merkle Tree.\n\n***** DONE General Game Definitions -- [[file:FraudProof/Games/GameDef.lean][GameDefs]]\nWho wins. Maybe as we define more adv games we may have more stuff here?\n***** DONE One Step Game -- [[file:FraudProof/Games/OneStepGame.lean][OneStepGame]]\nOne step game are games over a path of length 1. That is we have\ntwo hashes ~hb ht : Hash~ and proposers win if they can produce a /valid/\nsibling hash ~hb' : Hash~, that is ~opHash hb hb' = ht~.\n\nOther games eventually lead to this game.\n\n***** DONE [[file:FraudProof/Games/LinearGame.lean][Linear Game]] -- [[file:FraudProof/LinearGame.lean][LinearGame]]\nLinear games consist on one player proposing hashes along the one, one at a\ntime, and the chooser deciding if a hash is incorrect, challenging that claim.\n\nThe chooser either chooses between 'this hash is incorrect' or 'continue with\nthe next'. If the chooser challenges a correct hash, the chooser loses.\n\nIt can be player from the root to the leaf or the other way around.\n\n***** DONE Log Game -- [[file:FraudProof/Games/LogGame.lean][LogGame]]\n\nSimilar to the Linear one but instead of going through the list offering one by\none, the Proposer produces the hash in the middle of the path between the leaf\nand the root.\nThe chooser then chooses on which half the game should continue to.\n\nIt is called /Log Game/ since it halves the path at every instance. Leading to a one step game.\n\n**** DONE Players -- [[file:FraudProof/Players.lean][Players]]\nHere we define two players.\n***** DONE Proposer\nProposers propose hashes along the way.\nSince eventually they need to provide siblings too, proposer strategies are compose of two\narrays of hashes:\n#+begin_src lean :noeval\nstructure HC (n : Nat) where\n  -- Hashes along the way\n  pathNode : Fin ( n + 1 ) -\u003e Hash\n  -- Path elem knows how to hash.\n  pathSib : Fin n -\u003e PathElem\n#+end_src\nProposers are indexed on the length of the path.\n\nPlus some operations over proposers.\n****** IDEA Maybe. Min Proposer\nI guess we can implement a /minimal proposer/ using just an array of hashes as\nlong as the path itself.\nIt is just taking ~pathSib~ and computing ~pathNode~. But that only works for\nthe ~correct player~.\n***** DONE Chooser\nChoosers are somewhat simpler, but I haven't proved anything on them yet.\nThey take three hashes and choose which side (Left or Right) they want to\ncontinue playing in.\n*** DONE Winning Players -- [[file:FraudProof/Winning/Proposer.lean][WinningDefinitions]]\nThe goal here was to prove that /good proposers/ always win. That is that a player with some information, in particular, the original binary tree, can compute a winning strategy.\n\nTwo main concepts:\n+ What's the definition of a winning strategy?\n+ How to build a winning strategy from the information /honest/ player have?\n\n**** DONE Winning Proposer\nWinning proposers are path of a given length /connecting/ two hashes.\nBy connecting, I mean that the proposer propose hashes (nodes and siblings) that hash correct from one hsah to the other.\nWe can see it better in this three props:\n#+begin_src lean :noeval\n@[simp]\ndef GoodInit (h : Hash) := Player.pathNode 0 = h\n\n@[simp]\ndef GoodRoot (h : Hash ) := Player.pathNode ⟨ n , by simp ⟩ = h\n\n@[simp]\ndef GoodMid  :=\n    forall (m : Nat) (mLtn : m \u003c n ),\n    Player.pathNode ⟨ (m + 1) , by apply Nat.succ_lt_succ;assumption⟩ =\n    opHash ( Player.pathNode ⟨ m , by apply Nat.lt_add_one_of_lt; assumption ⟩) ( Player.pathSib ⟨ m , mLtn ⟩ )\n#+end_src\n\nWe also lift operations from strategies to /winning proposers/ (we'll need them\nwhen proving.)\n*** DONE Fraud Proof Games -- [[file:FraudProof.lean][FraudProofs]]\nMain file proving that:\n**** DONE Winning Proposers win Linear Game\n**** TODO Winning Proposers win Log Game\n*** TODO Chooser Guarantees\nIf someone wrongly challenges a posted Merkle Tree, we can defend it and win.\nIt is a similar theorem to winning strategies when challenged. But on the other side.\n\n**** DONE Main Idea: Path Skeletons\nWe need path skeletons to prove that choosers have winning strategies.\nTheorem is like:\n#+begin_quote\nFollowing the same path provided by proposers, correct choosers know the how to\nfill the same path with corrects hashes. Knowing that something is wrong, i.e.\nthe last hash proposed is wrong but the first is right (it is the hash of the\nroot assumed correct.), choosers can choose wisely when to challenge.\n#+end_quote\n**** DONE Linear games\nFound a bug here. My bad when defining hash props.\nFixed, but I made a bug in proof evident.\n**** TODO Log Games\n**** TODO Multicut games\n*** DONE Model Merkle Tree chain?\nShould we model the idea of posting Merkle Trees and the possibility of challenges.\n\n**** DONE Computing Hashes?\n\n#+begin_src bash :noeval\npython3 -m venv venv\nsource ./venv/bin/activate.fish\n\npython3 -m pip install web3\n#+end_src\n\nDelegating this to Python.\n#+begin_src python :noeval\nfrom web3 import web3 # hashfunctions.\n\nprint(web3.solidity_keccak(['string'],['testing']))\n#+end_src\n**** DONE Removing opaque types.\nSee 'Hash Classes'\n*** TODO Validity Proofs\n*** DONE Hash Classes\n#+begin_src Lean :noeval\n-- Hash function\n@[class] structure Hash (α ℍ : Type) where\n  mhash : α -\u003e ℍ\n-- Hash comb function\n@[class] structure HashMagma (ℍ : Type) where\n  comb : ℍ -\u003e ℍ -\u003e ℍ\n\n-- Laws\n-- Collision resistant?\n@[class] structure CollResistant (α ℍ : Type)[op : Hash α ℍ] where\n  -- Collision resistant? It should be hard to find these guys.\n  noCollisions : forall (a b : α), a ≠ b -\u003e op.mhash a ≠ op.mhash b\n\n-- Similar but for magma op.\n@[class] structure SLawFulHash (ℍ : Type)[m : HashMagma ℍ] where\n  -- Combine diff hashes are diff.\n  neqLeft : forall (a1 a2 b1 b2 : ℍ), a1 ≠ a2 -\u003e m.comb a1 b1 ≠ m.comb a2 b2\n  neqRight : forall (a1 a2 b1 b2 : ℍ), b1 ≠ b2 -\u003e m.comb a1 b1 ≠ m.comb a2 b2\n\n#+end_src\n*** DONE Hash Injective\nInjective prop is stronger than collision resistant and lawful.\n*** DONE IO Interactions\n**** DONE From Opaque to Classes\n**** DONE Keccak256 is a valid IO Hash?\n**** DONE IO Merkle Tree generation.\n*** TODO A bit more general games\n**** DONE DAs\nDAs are weird computational data.\n\\(\\{ a : \\alpha , b : \\beta \\}\\) and a process \\(f\\) such that \\( f(a) = b\\).\n**** DONE Skeletons in BTree/Tree computations.\n**** DONE Implementation of winning Defensive strategy and challenging strategies.\n**** TODO Proving the above?\n***** DONE DA : BTree -\u003e Merkle Tree\n***** TODO DA : (BTree -\u003e MTree) and Valid\nDepending on what the DA is, we may need different stuff.\n1. DA : \\(\\langle e , path , ha \\rangle\\) -- Tree is implicit and hashes to \\(ha\\)\n2. DA : \\(\\langle h(e) , path , ha \\rangle\\) -- Tree is implicit and hashes to \\(ha\\)\n3. DA : \\(\\langle tree ,  _ , path , ha \\rangle\\) -- Tree is |tree| and hashes to \\(ha\\)\n****** TODO Elements are f-Valid\n****** TODO No repeated elements\n** DONE Sequences to Vectors: Move on from Fin to Finite list\nGood things, we will not need \\(funext\\).\n#+begin_src lean4\ndef Sequence (n : Nat) (a : Type) := { ls : [ a ] // ls.length = n } -- Vector n a\n#+end_src\n** TODO Linear to Log using Generic Trees\n*** DONE Define Game transformations\n*** DONE Sequence Linear to Tree Linear\n*** TODO Sequence Linear to /Log/ Tree Linear\nI have been fighting with this one. I fall into the first model I actually\nproved correct. Tried to define some wierd transformations, nothing worked but I\nhave an idea.\n\nSame as before, I have two ways of seeing the sequence of hashes I have, as a\nsequence of siblings plus side or just computing each hash.\nI tried the sibling path, but it gets a bit fuzzy and it is not exactly what I\nneed when going though the logarithmic game. The logarithmic game is played only\nobserving the resulting intermediary hashes. Next step is to try to program that.\nI took the first path because it was an easy transformation, forming a tree game\narena with exactly what I had while computing intermediary hashes along the way.\nBut it turned out to be a bit complex, maybe I can come back to this idea after\ngaining some intuition about this.\n\n** Hash Function\nImplicit assumptions.\n\nHash functions are:\n + Collision resistants (from RDoC)\n\nI did not require it to prove strategies are correct when proving Merkle trees are\ncorrect.\n** Chooser Strategy.\nWhen an invalid hash tree is detected, we can invoke a choosers strategy to\ndebunk the block.\nThe strategy operates under the assumption the top hash is wrong, otherwise\nthere is no way to know if the agent proposing the block is wrong. For example,\nthe agent can front-run another and post what it seems to be a valid block\nwithout knowing the tree.\n\n*** TODO Optimization: We can build players choosing shorters paths when possible.\nWe know the whole tree and it is not complete.\n\n*** TODO Chooser generation stategy game.\nWe can define a game using generation strategies. If choosers provide inside\nknowledge of how they created their strategies, we can perform useful\ntransformation.\nHonest choosers know the data and thus, are part of this family.\n** Simultaneous games\nSince we have data behind Choosers now (and we generate functions based on that), we can play a simultaneous game.\nAt each step, both players reveal information and based on that the game progresses.\nI think they are equivalent, but I am leaving the proof of that to after FMBC.\n\n*** Simulatneous games -- Always sectioning games\nThe BoLD paper describes an optimization over the k-sectioning arbitration game.\nIt says that when the player choosing a side on a k-sectioning, it also provides\nthe ranges and the next sectioning, and roles are swapped.\nI do not fully understand how it works, but the idea is that sectioning happens at each move.\nThe only similar game I have is what I call simultaneous games, but I am not sure what they do yet.\n**** DONE Ask Marga what's her take\n\n* To build the whole project\n#+begin_src sh :noeval\nlake build\n#+end_src\n* L2Setchain FraudProofs\nData = batch tag , \\(\\langle id , h , \\sigma \\rangle \\) implicitly assigned to \\(b\\)\nwhere:\n+ symbol \\(\\sigma\\) seems to be a structure containing at least \\(f + 1\\) signatures\n+ symbol \\( h \\) is a hash??\n+ symbol \\( id\\) is an identification tag\n+ symbol \\( b \\) is a batch defined as a list/sequence of transactions?\n\nBatch tags are valid iff they hold 4 props (additional to the above) over the same 'da'?\n\nDA: This is the next valid batch tag corresponding to batch \\(b\\): \\(\\langle id, h , \\sigma \\rangle\\)\n\n** DONE Data availability Challenge ::\nData is unknown to a part of the network. It is not challenging the validity of\nthe DA. This challenge challenges missing data? and it makes sense because of economic rules.\n\nChallenge is over a specific node, notation here is very high level.\n\nIt is more on the lines of information retrieval than challenging results.\nThe way I was thinking about DAs was \\( data_{rep} , res \\) with two implicit\ncomputations \\( F(data) = data_{rep} \\wedge C(data) = res\\).\nHere the first part is the missing one, \\(F(data) = data_{rep}\\).\n\nAfter posting the tag, another agent ask for data indicating a node\n#+begin_src Lean :noeval\npathToN : Skeleton\n#+end_src\n\nThe original proposer then provides the information\n#+begin_src Lean :noeval\ndata ! pathToN = info\n#+end_src\n\nAnd then there is a challenge game to play. The DA the proposer just did is the following\nData hashes to \\(h\\) (already proposed) and such path goes to \\(info\\).\n#+begin_src Lean :noeval\n(data ! pathToN = info) \\and C(data) = h\n#+end_src\n\nIf information provided by the proposer, the challenger can challenge the whole\nsubtree. In Lean, we have a game just for that.\n\n** DONE Signature Challenge is just invoking a checker, one shoot game.\n\n** DONE Validity Challenge ::\n    Challenger knows there is an invalid transaction \\(e\\) in batch \\(t\\).\n    Game consists then on showing that \\(e \\in t\\) assuming \\(t\\) is the batch\n    corresponding to current batch tag \\(C(t) = h\\).\n    One player plays to prove \\(e \\in t\\), the other to prove the opposite.\n\n** DONE Integrity Challenge 1 ::\n    Two paths leading to the same element. similar to the above but with one extra\n    step, the defender should choose a path (the one that it thinks is wrong) and\n    play the ElementInTree game.\n\n** DONE Integrity Challenge 2 ::\n    Element \\(e\\) appears in two batches. Same as before but involving one paths in\n    each batch.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fimdea-software%2Fleanfraudproofs","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fimdea-software%2Fleanfraudproofs","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fimdea-software%2Fleanfraudproofs/lists"}