Production-ready DAC infra on Kubernetes. In this section, we will outline the steps to deploy a full DAC infrastructure on Kubernetes. This tutorial is cloud provider-agnostic. Prerequesites: a good understanding of Kubernetes. Kubernetes manifest files You can access the YAML files referenced in this section from this public repository, feel free to reuse and adapt them according to your needs. Outlook on the YAML files we got: configmap-env-vars.yaml: various environment variables and feature toggles.

Milestone: https://gitlab.com/tezos/tezos/-/milestones/156#tab-issues Design doc: https://hackmd.io/PBNbp7gfRbevwdnCjMlmng Open questions: https://hackmd.io/BUsS_LVvQ6eAinpHDymPcg Source code: grep -r "*_dac_*" in src/ Terms - what is it? DAC: Data Availability Committee Merkle-based hashing scheme: DAC datas/ DAC messages: these are the messages that will be fetched by the rollup node and applied them by the WASM PVM.

Quarter 1 report on Alcotezt, in this report, I will show what we have been accomplished and what we need to be doing next. People: Quyen, Arvid, Pietro Alcotezt translation Goal: The goal of alcotezt is to replace the dependence of alcotest and using the tezt. The wrap alcotezt was implemented to help this translation. Expectation to finish is Mid-April. Deliver: The translation can be split into two sections: for non-protocol tests and for protocol tests:Non-protocol tests: 38/47 MRs (8 MRs left to be merged) Protocol tests: 15/15 MRs

L features freeze will be on 16 Sept. Marigold proto-dev plan for L SCORU review party 2022-09-20 introducingdahsboard (wip) https://hackmd.io/wKSOWoE7QbG_V6dm-4Egbw Q4 roadmap (wip) https://miro.com/app/board/uXjVPVGRJGg=/?share_link_id=925048274576 review party -> tech party on Fri.

Developing on Tezos CRYPTO <img style="height:10vh" src="https://lh3.googleusercontent.com/ALdGKE7FInsc986r-8p5rnXB18FFYifi7sneKntG56c7czRDLbnb1EAwzCk44E4V6E3F_0EkiBZzqkJS52-SST4TY8Q5iAXRnB7Tng=w600">, NFT <img style="height:9vh" src="https://uploads-ssl.webflow.com/5b97453c8f2b579c7e60aaa3/5c26fbec58a0ba4e912bb8fd_sutu_reel_10.gif">, DEFI and much more <img style="height:4vh" src="https://hackmd.io/_uploads/ByjOweQqq.png">    Who am I? Tech Lead @ Marigold Tezos lover <img style="height:15vh" src="https://media1.giphy.com/media/Q5pVd08X8G5IqztOum/200w.gif?cid=82a1493by2fhf9178h11nipihb1hcvxu3ayrqlsrscn2yeah&rid=200w.gif&ct=g">

2023-June-15 Health (mental, physical) name=Pavlo:better, getting way too hot already. name=Quyen: I am doing good, just finished the Dungeon-game. What went well name=Pavlo:figured out how to split my work in smaller mr's

Introduction A rollup DApp for an interactive game. This "kernel" is a program run using <span style="color:green">rollup kernel-SDK</span>, <span style="color:green">sequencer prototype</span> (low-latency node) and <span style="color:green">React App</span> front-end. Motivation It is a second big kernel example after Tzwitter. Add a realistic example to demonstrate how to write WASM kernels to <span style="color:green">attract game devs</span>. Illustrate the use of a <span style="color:green">sequencer</span> to achieve low latency with a Smart Rollup. Motivation Identifies <span style="color:green">missing</span> tool/UX/etc. for the kernel-SDK, and sequencer prototype.

Starting date: 21-April-2023 Source code: dungeon. Goal Having an interactive game of dungeon adventure that shows how to build an realistic service on top of Tezos Smart Rollup. Deliverables Dungeon binariesWASM kernel Sequencer/low latency dApp (react; as the client)

Up until now, we implement everything inside a single file lib.rs. We can split this file into specific modules as follows: Modules a. Items:item.rs b. Map: map.rs c. Player: player.rs d. Player actions: player_actions.rs e. State: state.rs f. Storage storage.rs contains all the paths define in durable storage. Define functions for load_state and update_state.

The map structure represents the dungeon layout. A map has a series of tiles in a grid pattern. Each tile has a type describing how that tile is rendered. Map is represented as a vector. Each entry in the vector represents one tile. Represent tiles Tiles are limited to a pre-defined set of tile types. Tiles is an enum. It is a public enumeration named TileType with entries for walls and floors: #[derive(Clone, PartialEq)] pub enum TileType { Wall, Floor, }

Web2 vs Web3 Cas pratique produit Shifumi Speaker : Benjamin Fuentes Tech Lead @ Marigold Tezos lover <img style="height:15vh" src="https://media1.giphy.com/media/Q5pVd08X8G5IqztOum/200w.gif?cid=82a1493by2fhf9178h11nipihb1hcvxu3ayrqlsrscn2yeah&rid=200w.gif&ct=g"> <img style="height:20vh" src="https://external-content.duckduckgo.com/iu/?u=https%3A%2F%2Fniftycryptonomad.com%2Fwp-content%2Fuploads%2F2020%2F11%2FThe-Promise-of-Web3.0-owner-stakeholder-768x458.jpg&f=1&nofb=1&ipt=4775479cc731e85bb54194e8b3004a57c74d09185495c64d46b6dc9c55cc8ba8&ipo=images"> @benji_fuentes :bird:

Motivation The default latency (2 Tezos blocks) makes DApps feel clunky and limits the kind of applications people can write. Approaches Keep lowering block times. The Mumbai proposal for 15s will help a lotBut 15s is still a long time, and severly limits what can put on-chain. 1s response times seem to be the upper bound, after which users will report an app feels slow. Instant finality via bonded baker receipts.

[x] Create accounts [x] Twitter [ ] Blog posts translate to Vietnamese [x] Ticket for dummy [x] Gas for Tezos protocol developers Suggestion list:

Tickets in Deku-P The implementation of Deku-P is at the folder: deku-p/src/core, because Deku is designed to be a framework to implement parameteric chain like Deku-C or the Cookie-game. :::warning Notice that, at the moment, the implementation of Deku is very active, so the links may change theirs addresses. ::: Definition about Deku-P, Deku-C, Decookie. :::success :::spoiler

Knowlege - Learning about Token standards Standard tokens in Tezos FA1.2 and FA2 are standards token in Tezos. Token standards are a set of rules that ensure smooth interactions between different contracts operating with tokens. Token standards in Tezos are described in the Tezos Interoperability Proposal (TZIP) documents. Among other TZIPs, token standards are identified as Financial Applications (FA). There are 3 version of FA Tezos token standards: FA1 (TZIP 5 Abstract Ledger), this is already deprecated.

Knowledge - Kernel in SCORU Gather knowledge Big picture about SCORU and kernel :::spoiler A big picture of SCORU A talk by Yann and Hans about scaling Tezos with rollups: https://www.youtube.com/watch?v=SRDlaAhhKBY The relationship of the two VMs:

Time publish: not decice yet Michelson Views On December 3th 2021, the Tezos blockchain successfully upgraded by adopting Hangzhou at block $1,916,929$. In this upgrade, Michelson views has been introduced. Views are a new kind of entrypoints for smart contracts, which make internal state information more easily accessible to other smart contracts. In this article, we would like to give a statistic of views that have been used since then. Overview TODO: Post would provide a reminder just after the intro on "how use a view in ligo contract with Tezos.call_view" and "how use the view offchain with run_script_view RPC" Call-back view ...

Target: after the dynamic views MR is merged!!! New proposal "dynamic views" The advantage of views provides a synchronous way to fetch the data from another contract. This current feature cannot apply to contracts that deployed before the Hangzhou upgrade, or contracts that are deployed without declaring on-chain views in their codes. In this proposal, we want to provide a synchronous way as in views that able to fetch information from contracts that have been deployed. TODO: "Why we propose VIEW_EXEC ?" "How does VIEW_EXEC will ease dev onchain & offchain"? After the views feature introduced, the Sexp contracts have to upgraded their contracts to support views (write new "copy" contracts to include view and deployed them), this lead to the old contracts ... with this propose feature,

[toc] Specification of Dynamic views Summary We propose read-only access from a contract to another. A Michelson instruction VIEW_EXEC is added. Abstract Currently, we can fetch data from another contract synchronously thanks to the onchain views feature provides since the update of the Hangzhou's protocol. This, however, benefits to no contract who was originated before it. In this proposal, we propose to add a new view instruction, this view takes a lambda term of type s -> a as input, where s is the storage type of the target contract, and a is a value type derivable from s. By providing a proper lambda function, a contract could read anything from the target contract storage at will.

New Proposition for TZIP-18 New Proposition for TZIP-18 It is a copy of Hyperledger Fabric migration feature. It is comparable to the naive approach combined with internal proxy except that the proxy is managed by Tezos node and requires no more developer manual operations sequenceDiagram Admin->>Tezos: originate smart contract "A" version "1" with adminPolicy "AND(Admin,Admin2)" Tezos-->>Admin: contractAddress A version "1"