From 58c7b1e66305f3bcb7fe8865340661173cdd61d3 Mon Sep 17 00:00:00 2001 From: Luuk Date: Thu, 16 Feb 2023 20:45:42 +0100 Subject: [PATCH 01/16] fetch blogs --- packages/website/.gitignore | 1 + packages/website/components/BlogSection.tsx | 135 +++++++++----------- packages/website/components/getPosts.ts | 73 ----------- packages/website/package.json | 2 +- packages/website/scripts/getPosts.ts | 85 ++++++++++++ 5 files changed, 147 insertions(+), 149 deletions(-) delete mode 100644 packages/website/components/getPosts.ts create mode 100644 packages/website/scripts/getPosts.ts diff --git a/packages/website/.gitignore b/packages/website/.gitignore index f74c78183c9..9bceac0f582 100644 --- a/packages/website/.gitignore +++ b/packages/website/.gitignore @@ -1,2 +1,3 @@ .next node_modules +public \ No newline at end of file diff --git a/packages/website/components/BlogSection.tsx b/packages/website/components/BlogSection.tsx index 1f2bce4d975..ee8a259fbd1 100644 --- a/packages/website/components/BlogSection.tsx +++ b/packages/website/components/BlogSection.tsx @@ -1,5 +1,4 @@ import React, { useEffect, useState } from "react"; -import { getPosts } from "./getPosts"; interface Content { body: string; @@ -75,81 +74,16 @@ function getDateTime(timestamp: string): string { .padStart(2, "0")}-${date.getDate().toString().padStart(2, "0")}`; } -function checkIfPostAreSet(posts) { - if (posts.length > 0) { - return posts.map((post: Post) => ( -
-
- - - -
-
-
- -
- {post.content.title} -
-
- {post.wnft.description} -
- -
-
-
-
- - - {getReadingTime(post.content.body) + " min read"} -
-
-
-
-
- )); - } else { - const amountOfPostsToDisplay = 3; - return [...Array(amountOfPostsToDisplay)].map((v, i) => ( -
-
-
-
-
- )); - } -} - export default function BlogSection(): JSX.Element { const [posts, setPosts] = useState([]); - useEffect(() => { - getPosts.then((result : Post[]) => { - // only use the last three - result = result.sort((a, b) => b.content.timestamp - a.content.timestamp); - result = result.slice(0, 3); - - setPosts(result); - }); - // getting the information of the post via the arweave GraphQL and SDK + fetch("/posts.json") + .then((response) => response.json()) + .then((json) => { + json = json.sort((a, b) => b.content.timestamp - a.content.timestamp); + json = json.slice(0, 3); + setPosts(json); + }); }); return ( @@ -171,9 +105,60 @@ export default function BlogSection(): JSX.Element {
- {checkIfPostAreSet(posts)} + {posts.map((post: Post) => ( +
+
+ + + +
+
+ +
+
+
+ + + + {getReadingTime(post.content.body) + " min read"} + +
+
+
+
+
+ ))}
); -} +} \ No newline at end of file diff --git a/packages/website/components/getPosts.ts b/packages/website/components/getPosts.ts deleted file mode 100644 index 2ad504671da..00000000000 --- a/packages/website/components/getPosts.ts +++ /dev/null @@ -1,73 +0,0 @@ -import Arweave from "arweave"; - -const arweave = Arweave.init({ - host: "arweave.net", - port: 443, - protocol: "https", -}); - -export const getPosts = new Promise>((resolve, reject) => { - async function getTransanctionIds() { - await fetch('https://arweave.net/graphql', { - method: 'POST', - headers: { - 'Content-Type': 'application/json', - }, - body: JSON.stringify({ - query: ` - query { - transactions( - first: 100 - sort: HEIGHT_DESC - tags: [ - { - name: "Contributor" - values: ["0x5b796c4B197B6DfD413f177059C27963EB80af0F","0x2b1F13149C7F89622BBfB46Ae1e3ECc573Bb9331","0x381636D0E4eD0fa6aCF07D8fd821909Fb63c0d10"] - }, - { - name: "App-Name" - values: "MirrorXYZ" - } - ] - ) { - edges { - node { - id - tags { - name - value - } - } - - } - } - } - `}) - }).then((res) => res.json()) - .then((response) => { - getPosts(response); - }) - .catch(); - } - - async function getPosts(response) { - const posts = [] - Promise.all(response.data.transactions.edges.map((edge) => { - const transactionId = edge.node.id; - arweave.transactions - .getData(`${transactionId}`, { decode: true, string: true }).then((response: string) => JSON.parse(response)) - .then((data) => { - // Check if the posts have the required keys - if (data.hasOwnProperty('wnft')) { - - // add the original digest - data["OriginalDigest"] = edge.node.tags[4].value; - posts.push(data); - } - - }).catch(); - })) - resolve(posts); - } - getTransanctionIds(); -}) \ No newline at end of file diff --git a/packages/website/package.json b/packages/website/package.json index 07aff283ca5..2f6106a87b7 100644 --- a/packages/website/package.json +++ b/packages/website/package.json @@ -3,7 +3,7 @@ "version": "0.3.0", "private": true, "scripts": { - "build": "pnpm next build", + "build": "node scripts/test.ts && pnpm next build", "dev": "pnpm next dev", "start": "pnpm next start" }, diff --git a/packages/website/scripts/getPosts.ts b/packages/website/scripts/getPosts.ts new file mode 100644 index 00000000000..af83f9b91f1 --- /dev/null +++ b/packages/website/scripts/getPosts.ts @@ -0,0 +1,85 @@ +// import { Arweave } from 'arweave'; +const Arweave = require('arweave') +const fs = require('fs') + +const arweave = Arweave.init({ + host: "arweave.net", + port: 443, + protocol: "https", +}); + + +async function getTransanctionIds() { + await fetch('https://arweave.net/graphql', { + method: 'POST', + headers: { + 'Content-Type': 'application/json', + }, + body: JSON.stringify({ + query: ` + query { + transactions( + first: 100 + sort: HEIGHT_DESC + tags: [ + { + name: "Contributor" + values: ["0x5b796c4B197B6DfD413f177059C27963EB80af0F","0x2b1F13149C7F89622BBfB46Ae1e3ECc573Bb9331","0x381636D0E4eD0fa6aCF07D8fd821909Fb63c0d10"] + }, + { + name: "App-Name" + values: "MirrorXYZ" + } + ] + ) { + edges { + node { + id + tags { + name + value + } + } + } + } + } + `}) + }).then((res) => res.json()) + .then((response) => { + getPosts(response); + }) + .catch(); +} + +async function getPosts(response) { + const posts = [] + Promise.all(response.data.transactions.edges.map((edge) => { + const transactionId = edge.node.id; + arweave.transactions + .getData(`${transactionId}`, { decode: true, string: true }).then((response) => JSON.parse(response)) + .then((data) => { + // Check if the posts have the required keys + if (data.hasOwnProperty('wnft')) { + + // add the original digest + data["OriginalDigest"] = edge.node.tags[4].value; + posts.push(data); + } + + const jsonString = JSON.stringify(posts) + fs.writeFile('./public/posts.json', jsonString, err => { + if (err) { + console.log('Error writing file', err) + } else { + console.log('Successfully wrote file') + } + }) + + }).catch(); + })) + +} + +getTransanctionIds(); + +module.exports = {} \ No newline at end of file From 9d1b8f037518fed00799bd17adcd57d7cc4dadd4 Mon Sep 17 00:00:00 2001 From: Luuk Date: Thu, 16 Feb 2023 20:50:00 +0100 Subject: [PATCH 02/16] fix --- packages/website/package.json | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/packages/website/package.json b/packages/website/package.json index 2f6106a87b7..f9e23a81df9 100644 --- a/packages/website/package.json +++ b/packages/website/package.json @@ -3,7 +3,8 @@ "version": "0.3.0", "private": true, "scripts": { - "build": "node scripts/test.ts && pnpm next build", + "prebuild" : "node scripts/getPosts.ts", + "build": "pnpm next build", "dev": "pnpm next dev", "start": "pnpm next start" }, From cee1674ce322b6cb60844f182b087700b0de3450 Mon Sep 17 00:00:00 2001 From: Luuk Date: Thu, 16 Feb 2023 21:16:17 +0100 Subject: [PATCH 03/16] fix --- packages/website/package.json | 3 +-- packages/website/scripts/{getPosts.ts => getPosts.js} | 6 ++---- 2 files changed, 3 insertions(+), 6 deletions(-) rename packages/website/scripts/{getPosts.ts => getPosts.js} (96%) diff --git a/packages/website/package.json b/packages/website/package.json index f9e23a81df9..3a7643e600d 100644 --- a/packages/website/package.json +++ b/packages/website/package.json @@ -3,8 +3,7 @@ "version": "0.3.0", "private": true, "scripts": { - "prebuild" : "node scripts/getPosts.ts", - "build": "pnpm next build", + "build": "node scripts/getPosts.js && pnpm next build", "dev": "pnpm next dev", "start": "pnpm next start" }, diff --git a/packages/website/scripts/getPosts.ts b/packages/website/scripts/getPosts.js similarity index 96% rename from packages/website/scripts/getPosts.ts rename to packages/website/scripts/getPosts.js index af83f9b91f1..e3987877976 100644 --- a/packages/website/scripts/getPosts.ts +++ b/packages/website/scripts/getPosts.js @@ -1,4 +1,4 @@ -// import { Arweave } from 'arweave'; +// import Arweave from 'arweave'; const Arweave = require('arweave') const fs = require('fs') @@ -80,6 +80,4 @@ async function getPosts(response) { } -getTransanctionIds(); - -module.exports = {} \ No newline at end of file +getTransanctionIds(); \ No newline at end of file From b8e8864c205206499f669045fa94fa0a65b67705 Mon Sep 17 00:00:00 2001 From: Luuk Date: Thu, 16 Feb 2023 21:22:18 +0100 Subject: [PATCH 04/16] minor improvements --- packages/website/components/BlogSection.tsx | 2 +- packages/website/scripts/getPosts.js | 60 ++++++++++----------- 2 files changed, 29 insertions(+), 33 deletions(-) diff --git a/packages/website/components/BlogSection.tsx b/packages/website/components/BlogSection.tsx index ee8a259fbd1..98a7102e0bf 100644 --- a/packages/website/components/BlogSection.tsx +++ b/packages/website/components/BlogSection.tsx @@ -75,7 +75,7 @@ function getDateTime(timestamp: string): string { } export default function BlogSection(): JSX.Element { - const [posts, setPosts] = useState([]); + const [posts, setPosts] = useState([]); useEffect(() => { fetch("/posts.json") .then((response) => response.json()) diff --git a/packages/website/scripts/getPosts.js b/packages/website/scripts/getPosts.js index e3987877976..a36b0d26f9c 100644 --- a/packages/website/scripts/getPosts.js +++ b/packages/website/scripts/getPosts.js @@ -1,6 +1,6 @@ // import Arweave from 'arweave'; -const Arweave = require('arweave') -const fs = require('fs') +const Arweave = require("arweave"); +const fs = require("fs"); const arweave = Arweave.init({ host: "arweave.net", @@ -8,12 +8,11 @@ const arweave = Arweave.init({ protocol: "https", }); - async function getTransanctionIds() { - await fetch('https://arweave.net/graphql', { - method: 'POST', + await fetch("https://arweave.net/graphql", { + method: "POST", headers: { - 'Content-Type': 'application/json', + "Content-Type": "application/json", }, body: JSON.stringify({ query: ` @@ -43,8 +42,10 @@ async function getTransanctionIds() { } } } - `}) - }).then((res) => res.json()) + `, + }), + }) + .then((res) => res.json()) .then((response) => { getPosts(response); }) @@ -52,32 +53,27 @@ async function getTransanctionIds() { } async function getPosts(response) { - const posts = [] - Promise.all(response.data.transactions.edges.map((edge) => { - const transactionId = edge.node.id; - arweave.transactions - .getData(`${transactionId}`, { decode: true, string: true }).then((response) => JSON.parse(response)) - .then((data) => { - // Check if the posts have the required keys - if (data.hasOwnProperty('wnft')) { - - // add the original digest - data["OriginalDigest"] = edge.node.tags[4].value; - posts.push(data); - } - - const jsonString = JSON.stringify(posts) - fs.writeFile('./public/posts.json', jsonString, err => { - if (err) { - console.log('Error writing file', err) - } else { - console.log('Successfully wrote file') + const posts = []; + Promise.all( + response.data.transactions.edges.map((edge) => { + const transactionId = edge.node.id; + arweave.transactions + .getData(`${transactionId}`, { decode: true, string: true }) + .then((response) => JSON.parse(response)) + .then((data) => { + // Check if the posts have the required keys + if (data.hasOwnProperty("wnft")) { + // add the original digest + data["OriginalDigest"] = edge.node.tags[4].value; + posts.push(data); } - }) - - }).catch(); - })) + const jsonString = JSON.stringify(posts); + fs.writeFile("./public/posts.json", jsonString); + }) + .catch(); + }) + ); } getTransanctionIds(); \ No newline at end of file From a3feb7b99160d6709498ce6742381e9c4f2b2a4d Mon Sep 17 00:00:00 2001 From: Luuk Date: Thu, 16 Feb 2023 21:34:51 +0100 Subject: [PATCH 05/16] fix --- packages/website/scripts/getPosts.js | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/packages/website/scripts/getPosts.js b/packages/website/scripts/getPosts.js index c08851eb688..277b2d2feaa 100644 --- a/packages/website/scripts/getPosts.js +++ b/packages/website/scripts/getPosts.js @@ -69,7 +69,7 @@ async function getPosts(response) { } const jsonString = JSON.stringify(posts); - fs.writeFile("./public/posts.json", jsonString, err); + fs.writeFile("./public/posts.json", jsonString, (err) => {}); }) .catch(); }) From 55a407b3ea16e60cfdcda38f8d65b5743a585500 Mon Sep 17 00:00:00 2001 From: Luuk Date: Thu, 16 Feb 2023 21:38:30 +0100 Subject: [PATCH 06/16] clean up --- packages/website/scripts/getPosts.js | 1 - 1 file changed, 1 deletion(-) diff --git a/packages/website/scripts/getPosts.js b/packages/website/scripts/getPosts.js index 277b2d2feaa..696eb0be54c 100644 --- a/packages/website/scripts/getPosts.js +++ b/packages/website/scripts/getPosts.js @@ -1,4 +1,3 @@ -// import Arweave from 'arweave'; const Arweave = require("arweave"); const fs = require("fs"); From 56dad5b9a71f54b26cd38e09c61161f9e383699d Mon Sep 17 00:00:00 2001 From: Luuk Date: Fri, 17 Feb 2023 15:30:18 +0100 Subject: [PATCH 07/16] update contracts --- packages/protocol/contracts/L1/ProofVerifier.sol | 2 +- packages/protocol/contracts/L1/TaikoData.sol | 2 +- packages/protocol/contracts/L1/TaikoEvents.sol | 2 +- packages/protocol/contracts/L1/TaikoL1.sol | 2 +- packages/protocol/contracts/L1/TkoToken.sol | 2 +- packages/protocol/contracts/L1/libs/LibProposing.sol | 2 +- packages/protocol/contracts/L1/libs/LibProving.sol | 2 +- packages/protocol/contracts/L1/libs/LibUtils.sol | 2 +- packages/protocol/contracts/L1/libs/LibVerifying.sol | 2 +- packages/protocol/contracts/L2/TaikoL2.sol | 2 +- packages/protocol/contracts/bridge/Bridge.sol | 2 +- packages/protocol/contracts/bridge/BridgedERC20.sol | 2 +- packages/protocol/contracts/bridge/EtherVault.sol | 2 +- packages/protocol/contracts/bridge/IBridge.sol | 2 +- packages/protocol/contracts/bridge/TokenVault.sol | 2 +- packages/protocol/contracts/bridge/libs/LibBridgeData.sol | 2 +- packages/protocol/contracts/bridge/libs/LibBridgeInvoke.sol | 2 +- packages/protocol/contracts/bridge/libs/LibBridgeProcess.sol | 2 +- packages/protocol/contracts/bridge/libs/LibBridgeRelease.sol | 2 +- packages/protocol/contracts/bridge/libs/LibBridgeRetry.sol | 2 +- packages/protocol/contracts/bridge/libs/LibBridgeSend.sol | 2 +- packages/protocol/contracts/bridge/libs/LibBridgeStatus.sol | 2 +- packages/protocol/contracts/common/AddressResolver.sol | 2 +- packages/protocol/contracts/common/EssentialContract.sol | 2 +- packages/protocol/contracts/common/IAddressManager.sol | 2 +- packages/protocol/contracts/common/IHeaderSync.sol | 2 +- packages/protocol/contracts/common/IMintableERC20.sol | 2 +- packages/protocol/contracts/libs/Lib1559Math.sol | 2 +- packages/protocol/contracts/libs/LibAddress.sol | 2 +- packages/protocol/contracts/libs/LibAnchorSignature.sol | 2 +- packages/protocol/contracts/libs/LibBlockHeader.sol | 2 +- packages/protocol/contracts/libs/LibInvalidTxList.sol | 2 +- packages/protocol/contracts/libs/LibMath.sol | 2 +- packages/protocol/contracts/libs/LibReceiptDecoder.sol | 2 +- packages/protocol/contracts/libs/LibSharedConfig.sol | 2 +- packages/protocol/contracts/libs/LibTrieProof.sol | 2 +- packages/protocol/contracts/libs/LibTxDecoder.sol | 2 +- packages/protocol/contracts/libs/LibTxUtils.sol | 2 +- packages/protocol/contracts/libs/LibUint512Math.sol | 2 +- packages/protocol/contracts/libs/LibZKP.sol | 2 +- packages/protocol/contracts/signal/ISignalService.sol | 2 +- packages/protocol/contracts/signal/SignalService.sol | 2 +- packages/protocol/contracts/test/L1/TestTaikoL1.sol | 2 +- .../protocol/contracts/test/L1/TestTaikoL1EnableTokenomics.sol | 2 +- packages/protocol/contracts/test/L1/TestTaikoL2.sol | 2 +- .../contracts/test/L1/TestTaikoL2EnablePublicInputsCheck.sol | 2 +- packages/protocol/contracts/test/bridge/BullToken.sol | 2 +- packages/protocol/contracts/test/bridge/TestHeaderSync.sol | 2 +- .../protocol/contracts/test/bridge/libs/TestBadReceiver.sol | 2 +- .../protocol/contracts/test/bridge/libs/TestLibBridgeData.sol | 2 +- .../protocol/contracts/test/bridge/libs/TestLibBridgeInvoke.sol | 2 +- .../contracts/test/bridge/libs/TestLibBridgeProcess.sol | 2 +- .../protocol/contracts/test/bridge/libs/TestLibBridgeRetry.sol | 2 +- .../protocol/contracts/test/bridge/libs/TestLibBridgeSend.sol | 2 +- packages/protocol/contracts/test/bridge/libs/TestReceiver.sol | 2 +- packages/protocol/contracts/test/libs/TestLib1559Math.sol | 2 +- .../protocol/contracts/test/libs/TestLibAnchorSignature.sol | 2 +- packages/protocol/contracts/test/libs/TestLibBlockHeader.sol | 2 +- packages/protocol/contracts/test/libs/TestLibProving.sol | 2 +- packages/protocol/contracts/test/libs/TestLibReceiptDecoder.sol | 2 +- packages/protocol/contracts/test/libs/TestLibTrieProof.sol | 2 +- packages/protocol/contracts/test/libs/TestLibTxUtils.sol | 2 +- packages/protocol/contracts/test/thirdparty/TestERC20.sol | 2 +- .../contracts/test/thirdparty/TestLibBlockHeaderDecoder.sol | 2 +- .../protocol/contracts/test/thirdparty/TestLibMerkleTrie.sol | 2 +- .../protocol/contracts/test/thirdparty/TestLibRLPReader.sol | 2 +- .../protocol/contracts/test/thirdparty/TestLibRLPWriter.sol | 2 +- .../contracts/test/thirdparty/TestLibSecureMerkleTrie.sol | 2 +- .../protocol/contracts/test/thirdparty/TestMessageSender.sol | 2 +- packages/protocol/contracts/test/thirdparty/TestTKOToken.sol | 2 +- packages/protocol/contracts/thirdparty/AddressManager.sol | 2 +- .../protocol/contracts/thirdparty/LibBlockHeaderDecoder.sol | 2 +- packages/protocol/contracts/thirdparty/LibBytesUtils.sol | 2 +- packages/protocol/contracts/thirdparty/LibMerkleTrie.sol | 2 +- packages/protocol/contracts/thirdparty/LibRLPReader.sol | 2 +- packages/protocol/contracts/thirdparty/LibRLPWriter.sol | 2 +- packages/protocol/contracts/thirdparty/LibSecureMerkleTrie.sol | 2 +- 77 files changed, 77 insertions(+), 77 deletions(-) diff --git a/packages/protocol/contracts/L1/ProofVerifier.sol b/packages/protocol/contracts/L1/ProofVerifier.sol index 621e114e557..9323cc34c51 100644 --- a/packages/protocol/contracts/L1/ProofVerifier.sol +++ b/packages/protocol/contracts/L1/ProofVerifier.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; import "../common/EssentialContract.sol"; import "../libs/LibZKP.sol"; diff --git a/packages/protocol/contracts/L1/TaikoData.sol b/packages/protocol/contracts/L1/TaikoData.sol index 63cc52ff3ec..41886b9bcea 100644 --- a/packages/protocol/contracts/L1/TaikoData.sol +++ b/packages/protocol/contracts/L1/TaikoData.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; /// @author dantaik library TaikoData { diff --git a/packages/protocol/contracts/L1/TaikoEvents.sol b/packages/protocol/contracts/L1/TaikoEvents.sol index 8d5b08979ca..88c52d1f3ba 100644 --- a/packages/protocol/contracts/L1/TaikoEvents.sol +++ b/packages/protocol/contracts/L1/TaikoEvents.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; import "./TaikoData.sol"; diff --git a/packages/protocol/contracts/L1/TaikoL1.sol b/packages/protocol/contracts/L1/TaikoL1.sol index d8220682b9c..7d9ddf55b7a 100644 --- a/packages/protocol/contracts/L1/TaikoL1.sol +++ b/packages/protocol/contracts/L1/TaikoL1.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; import "../common/EssentialContract.sol"; import "../common/IHeaderSync.sol"; diff --git a/packages/protocol/contracts/L1/TkoToken.sol b/packages/protocol/contracts/L1/TkoToken.sol index 7c733f83656..78e5eeba5a9 100644 --- a/packages/protocol/contracts/L1/TkoToken.sol +++ b/packages/protocol/contracts/L1/TkoToken.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; import "@openzeppelin/contracts-upgradeable/utils/math/SafeCastUpgradeable.sol"; diff --git a/packages/protocol/contracts/L1/libs/LibProposing.sol b/packages/protocol/contracts/L1/libs/LibProposing.sol index 3ce587aff3c..40b226d4fab 100644 --- a/packages/protocol/contracts/L1/libs/LibProposing.sol +++ b/packages/protocol/contracts/L1/libs/LibProposing.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; import "../../libs/LibTxDecoder.sol"; import "../TkoToken.sol"; diff --git a/packages/protocol/contracts/L1/libs/LibProving.sol b/packages/protocol/contracts/L1/libs/LibProving.sol index 77f5617e78c..b6f102313f2 100644 --- a/packages/protocol/contracts/L1/libs/LibProving.sol +++ b/packages/protocol/contracts/L1/libs/LibProving.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; import {IProofVerifier} from "../ProofVerifier.sol"; import "../../common/AddressResolver.sol"; diff --git a/packages/protocol/contracts/L1/libs/LibUtils.sol b/packages/protocol/contracts/L1/libs/LibUtils.sol index 52a76ffcc3b..a5d8749093d 100644 --- a/packages/protocol/contracts/L1/libs/LibUtils.sol +++ b/packages/protocol/contracts/L1/libs/LibUtils.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; import "@openzeppelin/contracts-upgradeable/utils/math/SafeCastUpgradeable.sol"; diff --git a/packages/protocol/contracts/L1/libs/LibVerifying.sol b/packages/protocol/contracts/L1/libs/LibVerifying.sol index ad5b1ad21ae..31b9be8f2b1 100644 --- a/packages/protocol/contracts/L1/libs/LibVerifying.sol +++ b/packages/protocol/contracts/L1/libs/LibVerifying.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; import "../../common/AddressResolver.sol"; import "../TkoToken.sol"; diff --git a/packages/protocol/contracts/L2/TaikoL2.sol b/packages/protocol/contracts/L2/TaikoL2.sol index 4a184b86d69..ff65e98b70a 100644 --- a/packages/protocol/contracts/L2/TaikoL2.sol +++ b/packages/protocol/contracts/L2/TaikoL2.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; import "@openzeppelin/contracts/token/ERC20/IERC20.sol"; import "@openzeppelin/contracts/security/ReentrancyGuard.sol"; diff --git a/packages/protocol/contracts/bridge/Bridge.sol b/packages/protocol/contracts/bridge/Bridge.sol index 5d515579ee5..7de933dc339 100644 --- a/packages/protocol/contracts/bridge/Bridge.sol +++ b/packages/protocol/contracts/bridge/Bridge.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; import "../common/EssentialContract.sol"; import "./IBridge.sol"; diff --git a/packages/protocol/contracts/bridge/BridgedERC20.sol b/packages/protocol/contracts/bridge/BridgedERC20.sol index b2cfb831723..0dd9935cf3d 100644 --- a/packages/protocol/contracts/bridge/BridgedERC20.sol +++ b/packages/protocol/contracts/bridge/BridgedERC20.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; import "@openzeppelin/contracts-upgradeable/token/ERC20/IERC20Upgradeable.sol"; // solhint-disable-next-line max-line-length diff --git a/packages/protocol/contracts/bridge/EtherVault.sol b/packages/protocol/contracts/bridge/EtherVault.sol index 275ce8d301a..b7613e2c25a 100644 --- a/packages/protocol/contracts/bridge/EtherVault.sol +++ b/packages/protocol/contracts/bridge/EtherVault.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; // solhint-disable-next-line max-line-length import "@openzeppelin/contracts-upgradeable/token/ERC20/utils/SafeERC20Upgradeable.sol"; diff --git a/packages/protocol/contracts/bridge/IBridge.sol b/packages/protocol/contracts/bridge/IBridge.sol index 200cf55497b..ea066414245 100644 --- a/packages/protocol/contracts/bridge/IBridge.sol +++ b/packages/protocol/contracts/bridge/IBridge.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; /** * Bridge interface. diff --git a/packages/protocol/contracts/bridge/TokenVault.sol b/packages/protocol/contracts/bridge/TokenVault.sol index 3b2adf9116a..828144d0ae1 100644 --- a/packages/protocol/contracts/bridge/TokenVault.sol +++ b/packages/protocol/contracts/bridge/TokenVault.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; // solhint-disable-next-line max-line-length import "@openzeppelin/contracts-upgradeable/token/ERC20/utils/SafeERC20Upgradeable.sol"; diff --git a/packages/protocol/contracts/bridge/libs/LibBridgeData.sol b/packages/protocol/contracts/bridge/libs/LibBridgeData.sol index ff7160de6be..e030e5c7c43 100644 --- a/packages/protocol/contracts/bridge/libs/LibBridgeData.sol +++ b/packages/protocol/contracts/bridge/libs/LibBridgeData.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; import "../../common/AddressResolver.sol"; import "../../libs/LibAddress.sol"; diff --git a/packages/protocol/contracts/bridge/libs/LibBridgeInvoke.sol b/packages/protocol/contracts/bridge/libs/LibBridgeInvoke.sol index b6d198ca18e..8df2e0b2ffd 100644 --- a/packages/protocol/contracts/bridge/libs/LibBridgeInvoke.sol +++ b/packages/protocol/contracts/bridge/libs/LibBridgeInvoke.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; import "./LibBridgeData.sol"; diff --git a/packages/protocol/contracts/bridge/libs/LibBridgeProcess.sol b/packages/protocol/contracts/bridge/libs/LibBridgeProcess.sol index 9b149ba891d..12a9a730c5d 100644 --- a/packages/protocol/contracts/bridge/libs/LibBridgeProcess.sol +++ b/packages/protocol/contracts/bridge/libs/LibBridgeProcess.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; import "../../signal/ISignalService.sol"; import "../EtherVault.sol"; diff --git a/packages/protocol/contracts/bridge/libs/LibBridgeRelease.sol b/packages/protocol/contracts/bridge/libs/LibBridgeRelease.sol index c7d7025315a..5882caa94d2 100644 --- a/packages/protocol/contracts/bridge/libs/LibBridgeRelease.sol +++ b/packages/protocol/contracts/bridge/libs/LibBridgeRelease.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; import "../EtherVault.sol"; import "./LibBridgeData.sol"; diff --git a/packages/protocol/contracts/bridge/libs/LibBridgeRetry.sol b/packages/protocol/contracts/bridge/libs/LibBridgeRetry.sol index 58a0a12d562..ccb79ebef54 100644 --- a/packages/protocol/contracts/bridge/libs/LibBridgeRetry.sol +++ b/packages/protocol/contracts/bridge/libs/LibBridgeRetry.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; import "../EtherVault.sol"; import "./LibBridgeInvoke.sol"; diff --git a/packages/protocol/contracts/bridge/libs/LibBridgeSend.sol b/packages/protocol/contracts/bridge/libs/LibBridgeSend.sol index 7d5f8449e7b..f86fc9f11fd 100644 --- a/packages/protocol/contracts/bridge/libs/LibBridgeSend.sol +++ b/packages/protocol/contracts/bridge/libs/LibBridgeSend.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; import "../../signal/ISignalService.sol"; import "./LibBridgeData.sol"; diff --git a/packages/protocol/contracts/bridge/libs/LibBridgeStatus.sol b/packages/protocol/contracts/bridge/libs/LibBridgeStatus.sol index f93e435c5a2..30d269ebd2f 100644 --- a/packages/protocol/contracts/bridge/libs/LibBridgeStatus.sol +++ b/packages/protocol/contracts/bridge/libs/LibBridgeStatus.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; import "../../common/IHeaderSync.sol"; import "../../libs/LibBlockHeader.sol"; diff --git a/packages/protocol/contracts/common/AddressResolver.sol b/packages/protocol/contracts/common/AddressResolver.sol index f3ef4a24fe6..a00a1e0e7fc 100644 --- a/packages/protocol/contracts/common/AddressResolver.sol +++ b/packages/protocol/contracts/common/AddressResolver.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; import "@openzeppelin/contracts/utils/Strings.sol"; import "./IAddressManager.sol"; diff --git a/packages/protocol/contracts/common/EssentialContract.sol b/packages/protocol/contracts/common/EssentialContract.sol index 7973fc04385..cfd783f8082 100644 --- a/packages/protocol/contracts/common/EssentialContract.sol +++ b/packages/protocol/contracts/common/EssentialContract.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; import "@openzeppelin/contracts-upgradeable/access/OwnableUpgradeable.sol"; // solhint-disable-next-line max-line-length diff --git a/packages/protocol/contracts/common/IAddressManager.sol b/packages/protocol/contracts/common/IAddressManager.sol index 77cec20ade0..a5c6ab046df 100644 --- a/packages/protocol/contracts/common/IAddressManager.sol +++ b/packages/protocol/contracts/common/IAddressManager.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; /** * @author dantaik diff --git a/packages/protocol/contracts/common/IHeaderSync.sol b/packages/protocol/contracts/common/IHeaderSync.sol index 586d27046c4..8f64a77408e 100644 --- a/packages/protocol/contracts/common/IHeaderSync.sol +++ b/packages/protocol/contracts/common/IHeaderSync.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; /** * Interface implemented by both the TaikoL1 and TaikoL2 contracts. It exposes diff --git a/packages/protocol/contracts/common/IMintableERC20.sol b/packages/protocol/contracts/common/IMintableERC20.sol index 047679fb96c..aeb48d98206 100644 --- a/packages/protocol/contracts/common/IMintableERC20.sol +++ b/packages/protocol/contracts/common/IMintableERC20.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; import "@openzeppelin/contracts-upgradeable/token/ERC20/IERC20Upgradeable.sol"; diff --git a/packages/protocol/contracts/libs/Lib1559Math.sol b/packages/protocol/contracts/libs/Lib1559Math.sol index 63661f28110..06746912a71 100644 --- a/packages/protocol/contracts/libs/Lib1559Math.sol +++ b/packages/protocol/contracts/libs/Lib1559Math.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; /** * @author dantaik diff --git a/packages/protocol/contracts/libs/LibAddress.sol b/packages/protocol/contracts/libs/LibAddress.sol index 3606c9ec23f..61391c50a10 100644 --- a/packages/protocol/contracts/libs/LibAddress.sol +++ b/packages/protocol/contracts/libs/LibAddress.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; /** * This library offers address-related methods. diff --git a/packages/protocol/contracts/libs/LibAnchorSignature.sol b/packages/protocol/contracts/libs/LibAnchorSignature.sol index 4bb36e83ec6..69962ac0101 100644 --- a/packages/protocol/contracts/libs/LibAnchorSignature.sol +++ b/packages/protocol/contracts/libs/LibAnchorSignature.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; import "./LibUint512Math.sol"; diff --git a/packages/protocol/contracts/libs/LibBlockHeader.sol b/packages/protocol/contracts/libs/LibBlockHeader.sol index 9873eb540fc..30ebe075de9 100644 --- a/packages/protocol/contracts/libs/LibBlockHeader.sol +++ b/packages/protocol/contracts/libs/LibBlockHeader.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; import "../thirdparty/LibRLPWriter.sol"; diff --git a/packages/protocol/contracts/libs/LibInvalidTxList.sol b/packages/protocol/contracts/libs/LibInvalidTxList.sol index 6354f4c9942..99f6e50cd64 100644 --- a/packages/protocol/contracts/libs/LibInvalidTxList.sol +++ b/packages/protocol/contracts/libs/LibInvalidTxList.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; import "../L1/TaikoData.sol"; import "../libs/LibTxDecoder.sol"; diff --git a/packages/protocol/contracts/libs/LibMath.sol b/packages/protocol/contracts/libs/LibMath.sol index 1793c2f2da1..f1bcc74b66e 100644 --- a/packages/protocol/contracts/libs/LibMath.sol +++ b/packages/protocol/contracts/libs/LibMath.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; /** * @author dantaik diff --git a/packages/protocol/contracts/libs/LibReceiptDecoder.sol b/packages/protocol/contracts/libs/LibReceiptDecoder.sol index 5f939619ece..d14e9197379 100644 --- a/packages/protocol/contracts/libs/LibReceiptDecoder.sol +++ b/packages/protocol/contracts/libs/LibReceiptDecoder.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; import "../thirdparty/LibBytesUtils.sol"; import "../thirdparty/LibRLPReader.sol"; diff --git a/packages/protocol/contracts/libs/LibSharedConfig.sol b/packages/protocol/contracts/libs/LibSharedConfig.sol index 1a38a3dac22..bfde1b6d260 100644 --- a/packages/protocol/contracts/libs/LibSharedConfig.sol +++ b/packages/protocol/contracts/libs/LibSharedConfig.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; import "../L1/TaikoData.sol"; diff --git a/packages/protocol/contracts/libs/LibTrieProof.sol b/packages/protocol/contracts/libs/LibTrieProof.sol index 1b832ea4379..5d7e6a12f0e 100644 --- a/packages/protocol/contracts/libs/LibTrieProof.sol +++ b/packages/protocol/contracts/libs/LibTrieProof.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; import "../thirdparty/LibRLPReader.sol"; import "../thirdparty/LibRLPWriter.sol"; diff --git a/packages/protocol/contracts/libs/LibTxDecoder.sol b/packages/protocol/contracts/libs/LibTxDecoder.sol index 953dddf399c..edbd1973146 100644 --- a/packages/protocol/contracts/libs/LibTxDecoder.sol +++ b/packages/protocol/contracts/libs/LibTxDecoder.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; import "../thirdparty/LibBytesUtils.sol"; import "../thirdparty/LibRLPReader.sol"; diff --git a/packages/protocol/contracts/libs/LibTxUtils.sol b/packages/protocol/contracts/libs/LibTxUtils.sol index 840106f490b..c7ef36419a2 100644 --- a/packages/protocol/contracts/libs/LibTxUtils.sol +++ b/packages/protocol/contracts/libs/LibTxUtils.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; import "@openzeppelin/contracts/utils/cryptography/ECDSA.sol"; diff --git a/packages/protocol/contracts/libs/LibUint512Math.sol b/packages/protocol/contracts/libs/LibUint512Math.sol index 11fc66dfd25..16facea87b1 100644 --- a/packages/protocol/contracts/libs/LibUint512Math.sol +++ b/packages/protocol/contracts/libs/LibUint512Math.sol @@ -23,7 +23,7 @@ // TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE // SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; library LibUint512Math { /** diff --git a/packages/protocol/contracts/libs/LibZKP.sol b/packages/protocol/contracts/libs/LibZKP.sol index e30bdd51fcb..113356bef1d 100644 --- a/packages/protocol/contracts/libs/LibZKP.sol +++ b/packages/protocol/contracts/libs/LibZKP.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; library LibZKP { /********************* diff --git a/packages/protocol/contracts/signal/ISignalService.sol b/packages/protocol/contracts/signal/ISignalService.sol index c5d2bf01df9..cf4c18ff215 100644 --- a/packages/protocol/contracts/signal/ISignalService.sol +++ b/packages/protocol/contracts/signal/ISignalService.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; interface ISignalService { /** diff --git a/packages/protocol/contracts/signal/SignalService.sol b/packages/protocol/contracts/signal/SignalService.sol index 61920fe0fe9..d0dd7fdd0ea 100644 --- a/packages/protocol/contracts/signal/SignalService.sol +++ b/packages/protocol/contracts/signal/SignalService.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; import "../common/EssentialContract.sol"; import "../common/IHeaderSync.sol"; diff --git a/packages/protocol/contracts/test/L1/TestTaikoL1.sol b/packages/protocol/contracts/test/L1/TestTaikoL1.sol index c6b28ef0c07..3d9a9b61c7a 100644 --- a/packages/protocol/contracts/test/L1/TestTaikoL1.sol +++ b/packages/protocol/contracts/test/L1/TestTaikoL1.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; import {IProofVerifier} from "../../L1/ProofVerifier.sol"; import "../../L1/TaikoL1.sol"; diff --git a/packages/protocol/contracts/test/L1/TestTaikoL1EnableTokenomics.sol b/packages/protocol/contracts/test/L1/TestTaikoL1EnableTokenomics.sol index 6a593e7b4fa..c8fd3f04fce 100644 --- a/packages/protocol/contracts/test/L1/TestTaikoL1EnableTokenomics.sol +++ b/packages/protocol/contracts/test/L1/TestTaikoL1EnableTokenomics.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; import {IProofVerifier} from "../../L1/ProofVerifier.sol"; import "../../L1/TaikoL1.sol"; diff --git a/packages/protocol/contracts/test/L1/TestTaikoL2.sol b/packages/protocol/contracts/test/L1/TestTaikoL2.sol index 91642bbe58b..ae786c018e1 100644 --- a/packages/protocol/contracts/test/L1/TestTaikoL2.sol +++ b/packages/protocol/contracts/test/L1/TestTaikoL2.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; import "../../L2/TaikoL2.sol"; diff --git a/packages/protocol/contracts/test/L1/TestTaikoL2EnablePublicInputsCheck.sol b/packages/protocol/contracts/test/L1/TestTaikoL2EnablePublicInputsCheck.sol index dc5ff33b5f4..7f479f97bbc 100644 --- a/packages/protocol/contracts/test/L1/TestTaikoL2EnablePublicInputsCheck.sol +++ b/packages/protocol/contracts/test/L1/TestTaikoL2EnablePublicInputsCheck.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; import "../../L2/TaikoL2.sol"; diff --git a/packages/protocol/contracts/test/bridge/BullToken.sol b/packages/protocol/contracts/test/bridge/BullToken.sol index 86d2d0e82cc..7b8e59d8615 100644 --- a/packages/protocol/contracts/test/bridge/BullToken.sol +++ b/packages/protocol/contracts/test/bridge/BullToken.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; import "@openzeppelin/contracts/token/ERC20/ERC20.sol"; diff --git a/packages/protocol/contracts/test/bridge/TestHeaderSync.sol b/packages/protocol/contracts/test/bridge/TestHeaderSync.sol index 2afe3692b17..de1ae478463 100644 --- a/packages/protocol/contracts/test/bridge/TestHeaderSync.sol +++ b/packages/protocol/contracts/test/bridge/TestHeaderSync.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; import "../../common/IHeaderSync.sol"; diff --git a/packages/protocol/contracts/test/bridge/libs/TestBadReceiver.sol b/packages/protocol/contracts/test/bridge/libs/TestBadReceiver.sol index 69c811fa069..3deadd43611 100644 --- a/packages/protocol/contracts/test/bridge/libs/TestBadReceiver.sol +++ b/packages/protocol/contracts/test/bridge/libs/TestBadReceiver.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; // TODO(roger): Merge this file into TestReceiver.sol. contract TestBadReceiver { diff --git a/packages/protocol/contracts/test/bridge/libs/TestLibBridgeData.sol b/packages/protocol/contracts/test/bridge/libs/TestLibBridgeData.sol index 1b4f551c141..638ede8e6c3 100644 --- a/packages/protocol/contracts/test/bridge/libs/TestLibBridgeData.sol +++ b/packages/protocol/contracts/test/bridge/libs/TestLibBridgeData.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; import "../../../bridge/libs/LibBridgeData.sol"; import "../../../bridge/libs/LibBridgeStatus.sol"; diff --git a/packages/protocol/contracts/test/bridge/libs/TestLibBridgeInvoke.sol b/packages/protocol/contracts/test/bridge/libs/TestLibBridgeInvoke.sol index c3c47e4dae2..a3c9bca01af 100644 --- a/packages/protocol/contracts/test/bridge/libs/TestLibBridgeInvoke.sol +++ b/packages/protocol/contracts/test/bridge/libs/TestLibBridgeInvoke.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; import "../../../bridge/libs/LibBridgeInvoke.sol"; diff --git a/packages/protocol/contracts/test/bridge/libs/TestLibBridgeProcess.sol b/packages/protocol/contracts/test/bridge/libs/TestLibBridgeProcess.sol index 7c35d35f4bb..d5a3b4ca5fe 100644 --- a/packages/protocol/contracts/test/bridge/libs/TestLibBridgeProcess.sol +++ b/packages/protocol/contracts/test/bridge/libs/TestLibBridgeProcess.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; import "../../../common/EssentialContract.sol"; import "../../../bridge/libs/LibBridgeProcess.sol"; diff --git a/packages/protocol/contracts/test/bridge/libs/TestLibBridgeRetry.sol b/packages/protocol/contracts/test/bridge/libs/TestLibBridgeRetry.sol index d1ae2667ce9..9c72e9c2b0f 100644 --- a/packages/protocol/contracts/test/bridge/libs/TestLibBridgeRetry.sol +++ b/packages/protocol/contracts/test/bridge/libs/TestLibBridgeRetry.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; import "../../../common/EssentialContract.sol"; import "../../../bridge/libs/LibBridgeData.sol"; diff --git a/packages/protocol/contracts/test/bridge/libs/TestLibBridgeSend.sol b/packages/protocol/contracts/test/bridge/libs/TestLibBridgeSend.sol index ac6f028ddef..053c45ab273 100644 --- a/packages/protocol/contracts/test/bridge/libs/TestLibBridgeSend.sol +++ b/packages/protocol/contracts/test/bridge/libs/TestLibBridgeSend.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; import "../../../common/EssentialContract.sol"; import "../../../bridge/libs/LibBridgeSend.sol"; diff --git a/packages/protocol/contracts/test/bridge/libs/TestReceiver.sol b/packages/protocol/contracts/test/bridge/libs/TestReceiver.sol index ebc844885ab..94e1bc519c4 100644 --- a/packages/protocol/contracts/test/bridge/libs/TestReceiver.sol +++ b/packages/protocol/contracts/test/bridge/libs/TestReceiver.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; import "hardhat/console.sol"; diff --git a/packages/protocol/contracts/test/libs/TestLib1559Math.sol b/packages/protocol/contracts/test/libs/TestLib1559Math.sol index 1697131247a..9019662b7a6 100644 --- a/packages/protocol/contracts/test/libs/TestLib1559Math.sol +++ b/packages/protocol/contracts/test/libs/TestLib1559Math.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; import "../../libs/Lib1559Math.sol"; diff --git a/packages/protocol/contracts/test/libs/TestLibAnchorSignature.sol b/packages/protocol/contracts/test/libs/TestLibAnchorSignature.sol index 7f73b039f6a..38b4c4af914 100644 --- a/packages/protocol/contracts/test/libs/TestLibAnchorSignature.sol +++ b/packages/protocol/contracts/test/libs/TestLibAnchorSignature.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; import "../../libs/LibAnchorSignature.sol"; diff --git a/packages/protocol/contracts/test/libs/TestLibBlockHeader.sol b/packages/protocol/contracts/test/libs/TestLibBlockHeader.sol index 15e8e641841..6b02fa325bc 100644 --- a/packages/protocol/contracts/test/libs/TestLibBlockHeader.sol +++ b/packages/protocol/contracts/test/libs/TestLibBlockHeader.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; import "../../libs/LibBlockHeader.sol"; diff --git a/packages/protocol/contracts/test/libs/TestLibProving.sol b/packages/protocol/contracts/test/libs/TestLibProving.sol index ff5c2d8aae4..5234bd49b15 100644 --- a/packages/protocol/contracts/test/libs/TestLibProving.sol +++ b/packages/protocol/contracts/test/libs/TestLibProving.sol @@ -12,7 +12,7 @@ // @dev we need to update this when we update LibProving.sol -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; import "../../L1/libs/LibProving.sol"; import "../../common/AddressResolver.sol"; diff --git a/packages/protocol/contracts/test/libs/TestLibReceiptDecoder.sol b/packages/protocol/contracts/test/libs/TestLibReceiptDecoder.sol index 0e889ae9d91..03b0d2ad6ea 100644 --- a/packages/protocol/contracts/test/libs/TestLibReceiptDecoder.sol +++ b/packages/protocol/contracts/test/libs/TestLibReceiptDecoder.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; import "../../libs/LibReceiptDecoder.sol"; diff --git a/packages/protocol/contracts/test/libs/TestLibTrieProof.sol b/packages/protocol/contracts/test/libs/TestLibTrieProof.sol index a5bf2bf5a45..5328929bbef 100644 --- a/packages/protocol/contracts/test/libs/TestLibTrieProof.sol +++ b/packages/protocol/contracts/test/libs/TestLibTrieProof.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; import "../../libs/LibTrieProof.sol"; diff --git a/packages/protocol/contracts/test/libs/TestLibTxUtils.sol b/packages/protocol/contracts/test/libs/TestLibTxUtils.sol index 1c88e8318fa..b34f8362d76 100644 --- a/packages/protocol/contracts/test/libs/TestLibTxUtils.sol +++ b/packages/protocol/contracts/test/libs/TestLibTxUtils.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; import "../../libs/LibTxUtils.sol"; diff --git a/packages/protocol/contracts/test/thirdparty/TestERC20.sol b/packages/protocol/contracts/test/thirdparty/TestERC20.sol index 79da5f86d74..fa36ca8781b 100644 --- a/packages/protocol/contracts/test/thirdparty/TestERC20.sol +++ b/packages/protocol/contracts/test/thirdparty/TestERC20.sol @@ -1,6 +1,6 @@ // SPDX-License-Identifier: MIT -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; import "@openzeppelin/contracts/token/ERC20/ERC20.sol"; diff --git a/packages/protocol/contracts/test/thirdparty/TestLibBlockHeaderDecoder.sol b/packages/protocol/contracts/test/thirdparty/TestLibBlockHeaderDecoder.sol index defb1a8ec28..5e01167ac3e 100644 --- a/packages/protocol/contracts/test/thirdparty/TestLibBlockHeaderDecoder.sol +++ b/packages/protocol/contracts/test/thirdparty/TestLibBlockHeaderDecoder.sol @@ -4,7 +4,7 @@ // | |/ _` | | / / _ \ | |__/ _` | '_ (_-< // |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; import "../../thirdparty/LibBlockHeaderDecoder.sol"; diff --git a/packages/protocol/contracts/test/thirdparty/TestLibMerkleTrie.sol b/packages/protocol/contracts/test/thirdparty/TestLibMerkleTrie.sol index 23f8671908f..8a98bbc7b25 100644 --- a/packages/protocol/contracts/test/thirdparty/TestLibMerkleTrie.sol +++ b/packages/protocol/contracts/test/thirdparty/TestLibMerkleTrie.sol @@ -1,6 +1,6 @@ // SPDX-License-Identifier: MIT -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; /* Library Imports */ import {LibMerkleTrie} from "../../thirdparty/LibMerkleTrie.sol"; diff --git a/packages/protocol/contracts/test/thirdparty/TestLibRLPReader.sol b/packages/protocol/contracts/test/thirdparty/TestLibRLPReader.sol index 1a69b2dbbcb..9b665fba2f7 100644 --- a/packages/protocol/contracts/test/thirdparty/TestLibRLPReader.sol +++ b/packages/protocol/contracts/test/thirdparty/TestLibRLPReader.sol @@ -1,6 +1,6 @@ // SPDX-License-Identifier: MIT -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; import {LibRLPReader} from "../../thirdparty/LibRLPReader.sol"; diff --git a/packages/protocol/contracts/test/thirdparty/TestLibRLPWriter.sol b/packages/protocol/contracts/test/thirdparty/TestLibRLPWriter.sol index 2671c700a4f..6b4832eb764 100644 --- a/packages/protocol/contracts/test/thirdparty/TestLibRLPWriter.sol +++ b/packages/protocol/contracts/test/thirdparty/TestLibRLPWriter.sol @@ -1,6 +1,6 @@ // SPDX-License-Identifier: MIT -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; import {LibRLPWriter} from "../../thirdparty/LibRLPWriter.sol"; diff --git a/packages/protocol/contracts/test/thirdparty/TestLibSecureMerkleTrie.sol b/packages/protocol/contracts/test/thirdparty/TestLibSecureMerkleTrie.sol index 6c899ffc861..b88e97dd466 100644 --- a/packages/protocol/contracts/test/thirdparty/TestLibSecureMerkleTrie.sol +++ b/packages/protocol/contracts/test/thirdparty/TestLibSecureMerkleTrie.sol @@ -1,6 +1,6 @@ // SPDX-License-Identifier: MIT -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; /* Library Imports */ import {LibSecureMerkleTrie} from "../../thirdparty/LibSecureMerkleTrie.sol"; diff --git a/packages/protocol/contracts/test/thirdparty/TestMessageSender.sol b/packages/protocol/contracts/test/thirdparty/TestMessageSender.sol index f91591f1697..8835dfa9dc5 100644 --- a/packages/protocol/contracts/test/thirdparty/TestMessageSender.sol +++ b/packages/protocol/contracts/test/thirdparty/TestMessageSender.sol @@ -1,6 +1,6 @@ // SPDX-License-Identifier: MIT -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; import "../../bridge/IBridge.sol"; diff --git a/packages/protocol/contracts/test/thirdparty/TestTKOToken.sol b/packages/protocol/contracts/test/thirdparty/TestTKOToken.sol index 4a913152cfd..59796e5b189 100644 --- a/packages/protocol/contracts/test/thirdparty/TestTKOToken.sol +++ b/packages/protocol/contracts/test/thirdparty/TestTKOToken.sol @@ -1,6 +1,6 @@ // SPDX-License-Identifier: MIT -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; import "../../L1/TkoToken.sol"; contract TestTkoToken is TkoToken { diff --git a/packages/protocol/contracts/thirdparty/AddressManager.sol b/packages/protocol/contracts/thirdparty/AddressManager.sol index 115bdb4d188..2e17ca83458 100644 --- a/packages/protocol/contracts/thirdparty/AddressManager.sol +++ b/packages/protocol/contracts/thirdparty/AddressManager.sol @@ -29,7 +29,7 @@ // TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE // SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; /* External Imports */ import "@openzeppelin/contracts-upgradeable/access/OwnableUpgradeable.sol"; diff --git a/packages/protocol/contracts/thirdparty/LibBlockHeaderDecoder.sol b/packages/protocol/contracts/thirdparty/LibBlockHeaderDecoder.sol index ccbf989952e..1513e0df467 100644 --- a/packages/protocol/contracts/thirdparty/LibBlockHeaderDecoder.sol +++ b/packages/protocol/contracts/thirdparty/LibBlockHeaderDecoder.sol @@ -2,7 +2,7 @@ // Taken from https://github.com/privacy-scaling-explorations/zkevm-chain/blob/master/contracts/ZkEvmL2MessageDeliverer.sol#L23 // NOTE: No MIT license provided at the time, only SPDX-License-Identifier -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; /** * @title LibBlockHeaderDecoder diff --git a/packages/protocol/contracts/thirdparty/LibBytesUtils.sol b/packages/protocol/contracts/thirdparty/LibBytesUtils.sol index 23b2949ca76..69f27184251 100644 --- a/packages/protocol/contracts/thirdparty/LibBytesUtils.sol +++ b/packages/protocol/contracts/thirdparty/LibBytesUtils.sol @@ -24,7 +24,7 @@ // TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE // SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; /** * @title LibBytesUtils diff --git a/packages/protocol/contracts/thirdparty/LibMerkleTrie.sol b/packages/protocol/contracts/thirdparty/LibMerkleTrie.sol index bb4de176c66..5c5446858d3 100644 --- a/packages/protocol/contracts/thirdparty/LibMerkleTrie.sol +++ b/packages/protocol/contracts/thirdparty/LibMerkleTrie.sol @@ -24,7 +24,7 @@ // TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE // SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; /* Library Imports */ import {LibBytesUtils} from "./LibBytesUtils.sol"; diff --git a/packages/protocol/contracts/thirdparty/LibRLPReader.sol b/packages/protocol/contracts/thirdparty/LibRLPReader.sol index 9b4fb79be92..3df840372c8 100644 --- a/packages/protocol/contracts/thirdparty/LibRLPReader.sol +++ b/packages/protocol/contracts/thirdparty/LibRLPReader.sol @@ -24,7 +24,7 @@ // TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE // SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; /** * @title LibRLPReader diff --git a/packages/protocol/contracts/thirdparty/LibRLPWriter.sol b/packages/protocol/contracts/thirdparty/LibRLPWriter.sol index 7c50f134948..ae256de5e78 100644 --- a/packages/protocol/contracts/thirdparty/LibRLPWriter.sol +++ b/packages/protocol/contracts/thirdparty/LibRLPWriter.sol @@ -25,7 +25,7 @@ // TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE // SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; /** * @title LibRLPWriter diff --git a/packages/protocol/contracts/thirdparty/LibSecureMerkleTrie.sol b/packages/protocol/contracts/thirdparty/LibSecureMerkleTrie.sol index deebd47579f..8a8f63f597f 100644 --- a/packages/protocol/contracts/thirdparty/LibSecureMerkleTrie.sol +++ b/packages/protocol/contracts/thirdparty/LibSecureMerkleTrie.sol @@ -24,7 +24,7 @@ // TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE // SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. -pragma solidity ^0.8.9; +pragma solidity ^0.8.18; /* Library Imports */ import {LibMerkleTrie} from "./LibMerkleTrie.sol"; From f1ab2895a9978b55dedbc85d39dae02c2885933d Mon Sep 17 00:00:00 2001 From: Luuk Date: Fri, 17 Feb 2023 15:36:10 +0100 Subject: [PATCH 08/16] update contracts --- .../contracts/L1/TaikoCustomErrors.sol | 49 +++ packages/protocol/contracts/L1/TaikoL1.sol | 8 +- .../contracts/L1/libs/LibProposing.sol | 10 +- .../thirdparty/LibBlockHeaderDecoder.sol | 411 +++++++++--------- packages/website/.gitignore | 3 +- packages/website/public/posts.json | 1 + 6 files changed, 278 insertions(+), 204 deletions(-) create mode 100644 packages/protocol/contracts/L1/TaikoCustomErrors.sol create mode 100644 packages/website/public/posts.json diff --git a/packages/protocol/contracts/L1/TaikoCustomErrors.sol b/packages/protocol/contracts/L1/TaikoCustomErrors.sol new file mode 100644 index 00000000000..dfc7ebf8ebf --- /dev/null +++ b/packages/protocol/contracts/L1/TaikoCustomErrors.sol @@ -0,0 +1,49 @@ +// SPDX-License-Identifier: MIT +// _____ _ _ _ _ +// |_ _|_ _(_) |_____ | | __ _| |__ ___ +// | |/ _` | | / / _ \ | |__/ _` | '_ (_-< +// |_|\__,_|_|_\_\___/ |____\__,_|_.__/__/ + +pragma solidity ^0.8.9; + +/// @author david +abstract contract TaikoCustomErrors { + // The following custom errors must match the definitions in other V1 libraries. + error L1_0_FEE_BASE(); + error L1_ANCHOR_CALLDATA(); + error L1_ANCHOR_DEST(); + error L1_ANCHOR_GAS_LIMIT(); + error L1_ANCHOR_RECEIPT_ADDR(); + error L1_ANCHOR_RECEIPT_DATA(); + error L1_ANCHOR_RECEIPT_LOGS(); + error L1_ANCHOR_RECEIPT_PROOF(); + error L1_ANCHOR_RECEIPT_STATUS(); + error L1_ANCHOR_RECEIPT_TOPICS(); + error L1_ANCHOR_SIG_R(); + error L1_ANCHOR_SIG_S(); + error L1_ANCHOR_TYPE(); + error L1_BLOCK_NUMBER(); + error L1_CANNOT_BE_FIRST_PROVER(); + error L1_CIRCUIT_LENGTH(); + error L1_COMMITTED(); + error L1_CONFLICT_PROOF(); + error L1_DUP_PROVERS(); + error L1_EXTRA_DATA(); + error L1_GAS_LIMIT(); + error L1_HALTED(); + error L1_HALT_CONDITION(); + error L1_ID(); + error L1_INPUT_SIZE(); + error L1_METADATA_FIELD(); + error L1_META_MISMATCH(); + error L1_NOT_COMMITTED(); + error L1_NOT_FIRST_PROVER(); + error L1_PROOF_LENGTH(); + error L1_PROVER(); + error L1_SOLO_PROPOSER(); + error L1_TOO_LATE(); + error L1_TOO_MANY(); + error L1_TOO_MANY_PROVERS(); + error L1_TX_LIST(); + error L1_ZKP(); +} diff --git a/packages/protocol/contracts/L1/TaikoL1.sol b/packages/protocol/contracts/L1/TaikoL1.sol index 7d9ddf55b7a..ef7441bd6ab 100644 --- a/packages/protocol/contracts/L1/TaikoL1.sol +++ b/packages/protocol/contracts/L1/TaikoL1.sol @@ -12,6 +12,7 @@ import "../libs/LibAnchorSignature.sol"; import "../libs/LibSharedConfig.sol"; import "./TaikoData.sol"; import "./TaikoEvents.sol"; +import "./TaikoCustomErrors.sol"; import "./libs/LibProposing.sol"; import "./libs/LibProving.sol"; import "./libs/LibUtils.sol"; @@ -20,7 +21,12 @@ import "./libs/LibVerifying.sol"; /** * @author dantaik */ -contract TaikoL1 is EssentialContract, IHeaderSync, TaikoEvents { +contract TaikoL1 is + EssentialContract, + IHeaderSync, + TaikoEvents, + TaikoCustomErrors +{ using LibUtils for TaikoData.State; TaikoData.State public state; diff --git a/packages/protocol/contracts/L1/libs/LibProposing.sol b/packages/protocol/contracts/L1/libs/LibProposing.sol index 40b226d4fab..48d382c2495 100644 --- a/packages/protocol/contracts/L1/libs/LibProposing.sol +++ b/packages/protocol/contracts/L1/libs/LibProposing.sol @@ -109,9 +109,13 @@ library LibProposing { meta.l1Hash = blockhash(block.number - 1); meta.timestamp = uint64(block.timestamp); - // if multiple L2 blocks included in the same L1 block, - // their block.mixHash fields for randomness will be the same. - meta.mixHash = bytes32(block.difficulty); + // After The Merge, L1 mixHash contains the prevrandao + // from the beacon chain. Since multiple Taiko blocks + // can be proposed in one Ethereum block, we need to + // add salt to this random number as L2 mixHash + meta.mixHash = keccak256( + abi.encodePacked(block.prevrandao, state.nextBlockId) + ); } uint256 deposit; diff --git a/packages/protocol/contracts/thirdparty/LibBlockHeaderDecoder.sol b/packages/protocol/contracts/thirdparty/LibBlockHeaderDecoder.sol index 1513e0df467..f57b8ce4a7c 100644 --- a/packages/protocol/contracts/thirdparty/LibBlockHeaderDecoder.sol +++ b/packages/protocol/contracts/thirdparty/LibBlockHeaderDecoder.sol @@ -16,203 +16,218 @@ library LibBlockHeaderDecoder { /// @return _timestamp The timestamp /// @return _transactionsRoot The transactionsRoot /// @return _receiptsRoot The receiptsRoot - function decodeBlockHeader (bytes calldata blockHeader, bytes32 blockHash, bool postEIP1559) - public - pure - returns ( - bytes32 _stateRoot, - uint256 _timestamp, - bytes32 _transactionsRoot, - bytes32 _receiptsRoot - ) { - uint256 numFields = postEIP1559? 16:15; - assembly { - // TODO: use templating techniques and DRY code (with PatriciaValidator). - - // function Error(string) - function revertWith (msg) { - mstore(0, shl(224, 0x08c379a0)) - mstore(4, 32) - mstore(68, msg) - let msgLen - for {} msg {} { - msg := shl(8, msg) - msgLen := add(msgLen, 1) + function decodeBlockHeader( + bytes calldata blockHeader, + bytes32 blockHash, + bool postEIP1559 + ) + public + pure + returns ( + bytes32 _stateRoot, + uint256 _timestamp, + bytes32 _transactionsRoot, + bytes32 _receiptsRoot + ) + { + uint256 numFields = postEIP1559 ? 16 : 15; + assembly { + // TODO: use templating techniques and DRY code (with PatriciaValidator). + + // function Error(string) + function revertWith(msg) { + mstore(0, shl(224, 0x08c379a0)) + mstore(4, 32) + mstore(68, msg) + let msgLen + for { + + } msg { + + } { + msg := shl(8, msg) + msgLen := add(msgLen, 1) + } + mstore(36, msgLen) + revert(0, 100) + } + + // loads and aligns a value from calldata + // given the `len|offset` stored at `memPtr` + function loadValue(memPtr) -> value, len { + let tmp := mload(memPtr) + // assuming 0xffffff is sufficient for storing calldata offset + let offset := and(tmp, 0xffffff) + len := shr(128, tmp) + + if gt(len, 31) { + // special case - truncating the value is intended. + // this matches the behavior in `derivePath` that truncates to 256 bits. + offset := add(offset, sub(len, 32)) + value := calldataload(offset) + leave + } + + // everything else is + // < 32 bytes - align the value + let bits := mul(sub(32, len), 8) + value := calldataload(offset) + value := shr(bits, value) + } + + // returns the `len` of the whole RLP list at `ptr` + // and the offset for the first value inside the list. + function decodeListLength(ptr) -> len, startOffset { + let firstByte := byte(0, calldataload(ptr)) + + // SHORT LIST + // 0 - 55 bytes + // 0xc0 - 0xf7 + if lt(firstByte, 0xf8) { + len := sub(firstByte, 0xbf) + startOffset := add(ptr, 1) + leave + } + + // LONG LIST + // 0xf8 - 0xff + // > 55 bytes + { + let lenOf := sub(firstByte, 0xf7) + + // load the extended length + startOffset := add(ptr, 1) + let extendedLen := calldataload(startOffset) + let bits := sub(256, mul(lenOf, 8)) + extendedLen := shr(bits, extendedLen) + + len := add(extendedLen, lenOf) + len := add(len, 1) + startOffset := add(startOffset, lenOf) + leave + } + } + + // returns the calldata offset of the value and the length in bytes + // for the RLP encoded data item at `ptr`. + // used in `decodeFlat` + function decodeValue(ptr) -> dataLen, valueOffset, isData { + let firstByte := byte(0, calldataload(ptr)) + + // SINGLE BYTE + // 0x00 - 0x7f + if lt(firstByte, 0x80) { + dataLen := 1 + valueOffset := ptr + isData := 1 + leave + } + + // DATA ITEM + // 0 - 55 bytes long + // 0x80 - 0xb7 + if lt(firstByte, 0xb8) { + dataLen := sub(firstByte, 0x80) + valueOffset := add(ptr, 1) + isData := 1 + leave + } + + // LONG DATA ITEM + // > 55 bytes + // 0xb8 - 0xbf + if lt(firstByte, 0xc0) { + // the extended length is ignored + dataLen := sub(firstByte, 0xb7) + + // load the extended length + valueOffset := add(ptr, 1) + let extendedLen := calldataload(valueOffset) + let bits := sub(256, mul(dataLen, 8)) + valueOffset := add(ptr, dataLen) + dataLen := shr(bits, extendedLen) + leave + } + + // everything else is unexpected + revertWith("RLP") + } + + // decodes all RLP encoded data and stores their DATA items + // [length, calldata offset] in a continous memory region. + // Expects that the RLP starts with a list that defines the length + // of the whole RLP region. + function decodeFlat(_ptr) -> ptr, memStart, nItems, hash { + ptr := _ptr + + // load free memory ptr + // doesn't update the ptr and leaves the memory region dirty + memStart := mload(64) + + let payloadLen, startOffset := decodeListLength(ptr) + // reuse memStart region and hash + calldatacopy(memStart, ptr, payloadLen) + hash := keccak256(memStart, payloadLen) + + let memPtr := memStart + let ptrStop := add(ptr, payloadLen) + ptr := startOffset + + // decode until the end of the list + for { + + } lt(ptr, ptrStop) { + + } { + let len, valuePtr, isData := decodeValue(ptr) + ptr := add(len, valuePtr) + + if isData { + // store the length of the data and the calldata offset + let tmp := or(shl(128, len), valuePtr) + mstore(memPtr, tmp) + memPtr := add(memPtr, 32) + } + } + + nItems := div(sub(memPtr, memStart), 32) + } + + // expecting 16 individual items from the block header + let calldataPtr, memStart, nItems, hash := decodeFlat( + blockHeader.offset + ) + + // boundary check + if iszero( + eq(calldataPtr, add(blockHeader.offset, blockHeader.length)) + ) { + revertWith("BOUNDS") + } + if iszero(eq(hash, blockHash)) { + revertWith("HASH") + } + + // Depends on if EIP1559 is enabled, check the item size to be 15 or 16. + if iszero(eq(nItems, numFields)) { + revertWith("ITEMS") + } + + // at position 11 should be the timestamp + let len + _timestamp, len := loadValue(add(memStart, mul(32, 11))) + // sstore(originTimestamp.slot, value) + + // at position 3 should be the stateRoot + _stateRoot, len := loadValue(add(memStart, mul(32, 3))) + // sstore(originStateRoot.slot, value) + + // at position 4 should be transactionsRoot + _transactionsRoot, len := loadValue(add(memStart, mul(32, 4))) + // sstore(originTransactionsRoot.slot, value) + + // at position 5 should be receiptsRoot + _receiptsRoot, len := loadValue(add(memStart, mul(32, 5))) + // sstore(originReceiptsRoot.slot, value) } - mstore(36, msgLen) - revert(0, 100) - } - - // loads and aligns a value from calldata - // given the `len|offset` stored at `memPtr` - function loadValue (memPtr) -> value, len { - let tmp := mload(memPtr) - // assuming 0xffffff is sufficient for storing calldata offset - let offset := and(tmp, 0xffffff) - len := shr(128, tmp) - - if gt(len, 31) { - // special case - truncating the value is intended. - // this matches the behavior in `derivePath` that truncates to 256 bits. - offset := add(offset, sub(len, 32)) - value := calldataload(offset) - leave - } - - // everything else is - // < 32 bytes - align the value - let bits := mul( sub(32, len), 8) - value := calldataload(offset) - value := shr(bits, value) - } - - // returns the `len` of the whole RLP list at `ptr` - // and the offset for the first value inside the list. - function decodeListLength (ptr) -> len, startOffset { - let firstByte := byte(0, calldataload(ptr)) - - // SHORT LIST - // 0 - 55 bytes - // 0xc0 - 0xf7 - if lt(firstByte, 0xf8) { - len := sub(firstByte, 0xbf) - startOffset := add(ptr, 1) - leave - } - - // LONG LIST - // 0xf8 - 0xff - // > 55 bytes - { - let lenOf := sub(firstByte, 0xf7) - - // load the extended length - startOffset := add(ptr, 1) - let extendedLen := calldataload(startOffset) - let bits := sub(256, mul(lenOf, 8)) - extendedLen := shr(bits, extendedLen) - - len := add(extendedLen, lenOf) - len := add(len, 1) - startOffset := add(startOffset, lenOf) - leave - } - } - - // returns the calldata offset of the value and the length in bytes - // for the RLP encoded data item at `ptr`. - // used in `decodeFlat` - function decodeValue (ptr) -> dataLen, valueOffset, isData { - let firstByte := byte(0, calldataload(ptr)) - - // SINGLE BYTE - // 0x00 - 0x7f - if lt(firstByte, 0x80) { - dataLen := 1 - valueOffset := ptr - isData := 1 - leave - } - - // DATA ITEM - // 0 - 55 bytes long - // 0x80 - 0xb7 - if lt(firstByte, 0xb8) { - dataLen := sub(firstByte, 0x80) - valueOffset := add(ptr, 1) - isData := 1 - leave - } - - // LONG DATA ITEM - // > 55 bytes - // 0xb8 - 0xbf - if lt(firstByte, 0xc0) { - // the extended length is ignored - dataLen := sub(firstByte, 0xb7) - - // load the extended length - valueOffset := add(ptr, 1) - let extendedLen := calldataload(valueOffset) - let bits := sub(256, mul(dataLen, 8)) - valueOffset := add(ptr, dataLen) - dataLen := shr(bits, extendedLen) - leave - } - - // everything else is unexpected - revertWith('RLP') - } - - // decodes all RLP encoded data and stores their DATA items - // [length, calldata offset] in a continous memory region. - // Expects that the RLP starts with a list that defines the length - // of the whole RLP region. - function decodeFlat (_ptr) -> ptr, memStart, nItems, hash { - ptr := _ptr - - // load free memory ptr - // doesn't update the ptr and leaves the memory region dirty - memStart := mload(64) - - let payloadLen, startOffset := decodeListLength(ptr) - // reuse memStart region and hash - calldatacopy(memStart, ptr, payloadLen) - hash := keccak256(memStart, payloadLen) - - let memPtr := memStart - let ptrStop := add(ptr, payloadLen) - ptr := startOffset - - // decode until the end of the list - for {} lt(ptr, ptrStop) {} { - let len, valuePtr, isData := decodeValue(ptr) - ptr := add(len, valuePtr) - - if isData { - // store the length of the data and the calldata offset - let tmp := or(shl(128, len), valuePtr) - mstore(memPtr, tmp) - memPtr := add(memPtr, 32) - } - } - - nItems := div( sub(memPtr, memStart), 32 ) - } - - // expecting 16 individual items from the block header - let calldataPtr, memStart, nItems, hash := decodeFlat(blockHeader.offset) - - // boundary check - if iszero( eq(calldataPtr, add(blockHeader.offset, blockHeader.length)) ) { - revertWith('BOUNDS') - } - if iszero( eq(hash, blockHash) ) { - revertWith('HASH') - } - - // Depends on if EIP1559 is enabled, check the item size to be 15 or 16. - if iszero( eq(nItems, numFields) ) { - revertWith('ITEMS') - } - - // at position 11 should be the timestamp - let len - _timestamp, len := loadValue(add(memStart, mul(32, 11))) - // sstore(originTimestamp.slot, value) - - // at position 3 should be the stateRoot - _stateRoot, len := loadValue(add(memStart, mul(32, 3))) - // sstore(originStateRoot.slot, value) - - // at position 4 should be transactionsRoot - _transactionsRoot, len := loadValue(add(memStart, mul(32, 4))) - // sstore(originTransactionsRoot.slot, value) - - // at position 5 should be receiptsRoot - _receiptsRoot, len := loadValue(add(memStart, mul(32, 5))) - // sstore(originReceiptsRoot.slot, value) - - } - } } diff --git a/packages/website/.gitignore b/packages/website/.gitignore index 9bceac0f582..db5ddae553c 100644 --- a/packages/website/.gitignore +++ b/packages/website/.gitignore @@ -1,3 +1,2 @@ .next -node_modules -public \ No newline at end of file +node_modules \ No newline at end of file diff --git a/packages/website/public/posts.json b/packages/website/public/posts.json new file mode 100644 index 00000000000..f1fdbd30e7f --- /dev/null +++ b/packages/website/public/posts.json @@ -0,0 +1 @@ +[{"content":{"body":"Taiko Community Update #3 has arrived 🥁\n\nWe do these to provide transparency into the progress we’ve made since our [last community update](https://mirror.xyz/labs.taiko.eth/JdMMaBLOtK3Hk_SGZy_c9WFEnn1jDtOpfeXVHxJAtMU). These updates represent our most recent two-week work iteration.\n\n# Team wide ✨\n\n* Added the MIT License to [taiko-mono](https://github.com/taikoxyz/taiko-mono).\n\n* Posted a blog entry: [Taiko is fully open source](https://mirror.xyz/labs.taiko.eth/31vzkwgNaKNrze0oIv_wTKCw6Tha8OYQ6ffrquS3XUg).\n\n* Updated the Taiko website at [taiko.xyz](https://taiko.xyz/).\n\n* Added [protocol contract documentation](https://taiko.xyz/docs/category/smart-contracts) to the website.\n\n* Added language channels to the Discord. [Join us](https://discord.com/invite/taikoxyz)!\n\n* Minted [2022 Taiko Contributor (Founding Year) GitPOAPs](https://www.gitpoap.io/gp/686).\n\n# ZK-EVM 🔬\n\n* Added tests for math gadgets.\n\n* Adding support for skipping over invalid transactions in the circuits.\n\n* Reviewing and refactoring the Merkle Patricia Tree circuit.\n\n* Investigating alternative proving systems.\n\n# Protocol 🧑‍🔬\n\n* Simplified the protocol contract documentation.\n\n* Various small improvements and optimizations.\n\n# Node 🌐\n\n* Enable p2p blocks fast synchronization among L2 nodes.\n\n* Added the ability to enable prover allowlisting for the testnet.\n\n# Bridge 🌉\n\n* Worked on the bridge deployment.\n\n* Connecting the bridge UI with the relayer.\n\n* Improved bridge UI, including mobile responsiveness.\n\n\n---\n\n## Join us\n\nExplore open positions on our [job board](https://www.notion.so/taikoxyz/Taiko-Jobs-828fd7232d2c4150a11e10c8baa910a2).\n\n## Follow us\n\nJoin the community on Discord and follow us on Twitter!\n\nTo stay updated on the latest from Taiko:\n\n* Website: [https://taiko.xyz](https://taiko.xyz/)\n\n* Discord: \n\n* GitHub: \n\n* Reddit: [https://www.reddit.com/r/taiko_xyz](https://www.reddit.com/r/taiko_xyz/)\n\n* Twitter: \n\n## Contribute\n\nContribute to Taiko and earn a GitPOAP! You will also be featured as a contributor on our README. Get started with the [contributing guide](https://github.com/taikoxyz/taiko-mono/blob/main/CONTRIBUTING.md).\n\n## Thank you 🙏\n\nBig thanks to all our community members and contributors. ❤️\n\nWe might miss a few of you, but specific shoutouts to:\n\n* **omahs** for fixing a typo in the documentation\n\n* **1xDeFi** for adding the meaning of \"Taiko\" to [Frequently asked questions](https://taiko.xyz/faq#what-does-taiko-mean)\n\n* **Etherdad.lens** for the educational Twitter [thread](https://twitter.com/etherdad10/status/1600159537578721280)\n\n* **wolfderechter** for tidying up the footer links on [taiko.xyz](https://taiko.xyz/)\n\n* **Vitalik Buterin** for the recognition & [shout out on Twitter](https://twitter.com/taikoxyz/status/1600236704253689856)","timestamp":"1670537576","title":"Taiko Community Update #3"},"digest":"R_NMPTPUKrXhRYQS_v6Y6rpw_QvnjZmTvPYLS9YL23M","authorship":{"contributor":"0x2b1F13149C7F89622BBfB46Ae1e3ECc573Bb9331","signingKey":"{\"crv\":\"P-256\",\"ext\":true,\"key_ops\":[\"verify\"],\"kty\":\"EC\",\"x\":\"pn7a0q111AR7PdQJY_VEXF1ZsMx4wyPJvbErRkirSb8\",\"y\":\"k53QCfxPK3N6NoEF2_9P3EUfo6w3MLsUSJmISPVnXFk\"}","signature":"0x8a3a0425b477f54c0f8e963212b6238a7213b770fdae58b5a8f7f5e22baf77cd1fdcf43fb2ce72664fa98700370508237dd987bb4c995857b2505d0757ae8c8f1b","signingKeySignature":"Z4ehuQisTC2rw_UpbtmvBZbfDI5Gf0KiVu65xx1nkC3AsIANPxH0EwCe67_KIAIYTxnHwnTe1tkUwGcMxx2oIA","signingKeyMessage":"I authorize publishing on mirror.xyz from this device using:\n{\"crv\":\"P-256\",\"ext\":true,\"key_ops\":[\"verify\"],\"kty\":\"EC\",\"x\":\"pn7a0q111AR7PdQJY_VEXF1ZsMx4wyPJvbErRkirSb8\",\"y\":\"k53QCfxPK3N6NoEF2_9P3EUfo6w3MLsUSJmISPVnXFk\"}","algorithm":{"name":"ECDSA","hash":"SHA-256"}},"version":"04-25-2022","wnft":{"chainId":10,"description":"Taiko Community Update #3 has arrived 🥁\n","fee":250,"fundingRecipient":"0x5b796c4B197B6DfD413f177059C27963EB80af0F","imageURI":"QmQUVJvSeTrAqEzwjRg4c5MrMdWrvMEZqo1J6C3AjXJv7B","mediaAssetId":308118,"name":"Taiko Community Update #3","nonce":2705515,"owner":"0x2b1F13149C7F89622BBfB46Ae1e3ECc573Bb9331","price":0,"proxyAddress":"0xE73283Ebc2fC980aa83DF9De557077Ce21d54310","renderer":"0x0000000000000000000000000000000000000000","supply":500,"symbol":"TAIKOCOMMUNITYUPDATE3"},"OriginalDigest":"8E_7fjFNFjY7dIGAppqaNyuM-1QXp78AekXMA9--q6o"},{"content":{"body":"Dear Taiko community,\n\nWe would like to share an update with you about Taiko’s progress. Please [reach out](http://info@taiko.xyz/) if you have questions or suggestions.\n\n# Team\n\nIn July, Brecht Devos joined Taiko as our third co-founder. Brecht used to work for Loopring as the Chief Architect, but over the last 12 months or so, he had been working on [PSE](https://github.com/privacy-scaling-explorations)’s [zkEVM](https://github.com/privacy-scaling-explorations/zkevm-circuits) with researchers and engineers from the Ethereum Foundation and other open-source projects. Brecht leads Taiko’s Zero-Knowledge R&D team with an objective to implement all remaining EVM opcodes and to customize the zkEVM to fit Taiko’s layer 2 protocol design.\n\nWe have hired four cryptographers from Turkey, Austria, Barbados, and Ukraine. The first three have already been onboarded and Aleksei will join on November 1st.\n\nThere is also a new backend engineer joined in Shanghai and two protocol & frontend engineer from India and Canada. Two more engineers are joining us from the US to work on bridges.\n\nWe have also started to activate our Discord and Twitter communities, thanks to the involvement of our new community managers. They have already brought onboard several dedicated moderators to help attract, engage and retain a broader community.\n\nThe Taiko team is now a twenty persons team across twelve countries covering all continents with most people having an engineering/research background.\n\n![](https://images.mirror-media.xyz/publication-images/i65bAIoAy9kCFehfrbYlu.png?height=1800&width=3200)\n\n# Development\n\n### ZK-EVM\n\nMost opcodes are fully implemented in the EVM circuit, with a small number still remaining to be done. Work has started on adding support for so-called precompiled contracts which can be called from smart contracts and need special handling.\n\nA lot of progress has been made on the aggregation circuit, which is the circuit that allows the verification of proofs inside another proof. This is an important circuit for connecting the different ZK-EVM circuits together in a way that can be verified efficiently on Ethereum.\n\nBecause the goal is to build a type-1 (fully Ethereum-equivalent) ZK-EVM, we need to make sure there are no technical limitations that prevent us from building such a system. PLONKish circuits don't have any real limitations on what can be proven, but certain problems don't map very well to circuits, which results in high proving times. The hash functions used in Ethereum are a good example of this specifically for a type-1 ZK-EVM. Prover times can be improved by optimizations on the circuit level, optimizations on the prover level, and optimizations on the prover system level. Many such optimizations for the different ZK-EVM circuits have been done on the circuit level (e.g. keccak256/sha256) and on the prover level. We will be continuing these efforts, while the newly joined cryptography researchers will be able to help us to do optimizations on the prover system level as well.\n\n### Protocol\n\nWe deprecated Taiko protocol V1 (). V1 was built on top of Proof-of-Stake as we require that block proposers must prove their own blocks (which is no longer the case).\n\nThe new protocol (V2) has a different set of design objectives and assumptions on what a ZK-EVM can and cannot prove. As a [type-1 zkRollup](https://vitalik.ca/general/2022/08/04/zkevm.html), Taiko protocol V2 is more secure, minimal, robust, decentralized, permissionless, Ethereum-Aligned, and Ethereum-Equivalent. We have also mitigated MEV challenges with a commit-then-propose scheme. But the most powerful feature for users is the immediate block finality - people only need to wait for a L1 confirmation to have their Taiko L2 transactions finalized.\n\nThe new protocol has been implemented, reviewed, and is being used by the Taiko node software. However, it demands comprehensive unit and integration testing.\n\nOur [draft whitepaper](https://github.com/taikochain/whitepaper/releases/download/v1.0.0/taiko-whitepaper.pdf) is ready for you to review.\n\n![](https://images.mirror-media.xyz/publication-images/MWdBeHKvCtQyT7QG8EvsT.png?height=2116&width=3108)\n\n### Bridge\n\nWe have also re-implemented our default cross-chain bridge. The new bridge only assumes the two chains are both EVM-based and that some block headers are synchronized between the two chains on a regular basis. Bridge design is not covered by our whitepaper but the bridge source code is [open-sourced](https://github.com/taikochain/taiko-mono) together with our rollup protocol.\n\n### Node & Testnet\n\nOur new [node implementation](https://github.com/taikochain/client-mono) for protocol V2 takes a difference approach from V1: the new architectures is built on top of Ethereum’s engine API design and split into multiple binaries.\n\nWith this new design, we are able to maintain the a maximal level of compatibility with the go-ethereum codebase.\n\nThe private alpha-1 testnet with only a few nodes has been up and running without actual ZKPs. Nodes in alpha-1 are interacting with each other in simple ways. We are working to simulate more complex scenarios to further test inter-node and cross-layer interactions. A private blockchain explorer is up and running for internal development and testing purpose only.\n\n![](https://images.mirror-media.xyz/publication-images/1Ct0O7u5wcUKIzLWel2Bh.png?height=2164&width=2698)\n\nIt’s too early to request testnet access, your patience will be appreciated.\n\n## Future Updates\n\nMoving forward, Taiko Labs will share updates with our communities at the end of each quarter. We thank you for being part of our exciting journey.\n\n\n\n","timestamp":"1666529746","title":"Taiko Community Update - Q3 2022"},"digest":"A4bKjhlGqAFM9E3YvLHoAp29O4fW1lpVzlzMzThX1SY","authorship":{"contributor":"0x5b796c4B197B6DfD413f177059C27963EB80af0F","signingKey":"{\"crv\":\"P-256\",\"ext\":true,\"key_ops\":[\"verify\"],\"kty\":\"EC\",\"x\":\"Idj9037DpsOvwoPpOcL60W62ZKkqLnMgxzSZKU_R61I\",\"y\":\"rm2Tp_RyIHaQcKSfub2FY6Dhvw-wpXmqIpFFM_a6Ohg\"}","signature":"0xe61e02914b37b4dc18b1d57acfc5573cc18f129f632953fc485dfd2a45a3bf4e2c1945e1ca3dc85dcb6b4a348d0b7b1c62d08e52c3ca78bf36977187363c35a51c","signingKeySignature":"wBcUQHe309FCDSvTRlG60dbjyiagSgIfEteSy9_jUF3LyznQP-A07VIKTWVuHmxwiQzAHKnzbr-6N5mkUJr-yA","signingKeyMessage":"I authorize publishing on mirror.xyz from this device using:\n{\"crv\":\"P-256\",\"ext\":true,\"key_ops\":[\"verify\"],\"kty\":\"EC\",\"x\":\"Idj9037DpsOvwoPpOcL60W62ZKkqLnMgxzSZKU_R61I\",\"y\":\"rm2Tp_RyIHaQcKSfub2FY6Dhvw-wpXmqIpFFM_a6Ohg\"}","algorithm":{"name":"ECDSA","hash":"SHA-256"}},"version":"04-25-2022","wnft":{"chainId":10,"description":"Dear Taiko community,\n","fee":250,"fundingRecipient":"0x5b796c4B197B6DfD413f177059C27963EB80af0F","imageURI":"bafybeiajw4ckkw35iiw6blzoqmntrb5rfs6d6uwpirv7tgbhh2244kxqfq","mediaAssetId":250598,"name":"Taiko Community Update - Q3 2022","nonce":7755661,"owner":"0x5b796c4B197B6DfD413f177059C27963EB80af0F","price":0,"proxyAddress":"0xed8112AEB72684ce0Bb1fbB0e8B06FAd753b9299","renderer":"0x0000000000000000000000000000000000000000","supply":500,"symbol":"TAIKOCOMMUNITYUPDATE-Q32022"},"OriginalDigest":"dCl9V1KkqF99xlDbho6fAOm5zoqU4Irk7PymLMwTiCc"},{"content":{"body":"Hey everyone 👋, we want to update you on the progress we’ve made since our [last community update](https://mirror.xyz/labs.taiko.eth/dCl9V1KkqF99xlDbho6fAOm5zoqU4Irk7PymLMwTiCc).\n\n## R&D\n\n### Node & Client\n\n* Deployed a Grafana dashboard to monitor our own testnet nodes / services.\n\n* Deployed HIVE for the L2 nodes / services integration tests.\n\n### Protocol\n\n* Published the initial tokenomics proposal (in review), which can be viewed at the [latest whitepaper](https://taikoxyz.github.io/taiko-mono/taiko-whitepaper.pdf).\n\n* Reduced commitBlock gas cost (in review).\n\n### Bridge\n\n* Made progress on the bridge relayer and bridge UI.\n\n* Moved stack from React to Svelte + Tailwind + daisyUI.\n\n* Improved bridge documentation.\n\n### ZK-EVM\n\n* Miscellaneous contributions to the community [ZK-EVM project](https://github.com/privacy-scaling-explorations/zkevm-circuits) such as a `RETURENDATACOPY` opcode implementation and circuit benchmarks.\n\n* Ongoing investigation into newer proving systems (HyperPlonk, FRI based solutions) and circuit optimizations (non-native field arithmetic).\n\n### All\n\n* Open sourced [taiko-mono](https://github.com/taikoxyz/taiko-mono) with [contributing guide](https://github.com/taikoxyz/taiko-mono/blob/main/CONTRIBUTING.md).\n\n* Added code coverage calculations and badges for our projects.\n\n* Fleshed out requirements and design for the testnet launch.\n\n* Published the [Taiko jobs page](https://www.notion.so/Taiko-Jobs-828fd7232d2c4150a11e10c8baa910a2).\n\n* Updated all link handles to point to `taikoxyz` instead of `taikochain`.\n\n## Community\n\n### Events\n\nTalked about [Layer 2 Finality](https://hackmd.io/@taikolabs/HkN7GR64i) at the [IOSG conference](https://twitter.com/IOSGVC/status/1587432916753481729?s=20&t=GewTXWDoqCW3z9iqf83Nig) in Lisbon.\n\n### Discord\n\nAdded a new moderator, welcome `ex_sxcr`!\n\n### Website\n\n* Updated [taiko.xyz](http://taiko.xyz) with some good ‘getting started’ materials and a Talks section.\n\n* Moved all presentations from Google slides to HackMD, and added them to Talks.\n\n### Publications\n\n* Published an internal presentation from Daniel to new engineers at Taiko, explaining the Taiko protocol — this can be viewed on our new [YouTube channel](https://www.youtube.com/@taikoxyz).\n\n* Published a blog post on [The Type 1 ZK-EVM](https://mirror.xyz/labs.taiko.eth/w7NSKDeKfJoEy0p89I9feixKfdK-20JgWF9HZzxfeBo).\n\n### Contributors\n\n* Progress on GitPOAP for contributors has been made, you can look forward to that soon!\n\n* Added contributors section to the [taiko-mono README](https://github.com/taikoxyz/taiko-mono/blob/main/README.md).\n\n* Added [issue templates](https://github.com/taikoxyz/taiko-mono/issues/new/choose) so you can now easily report bugs and request features (will be recognized on our README and eligible for a GitPOAP).\n\n## Thank you\n\nAs a decentralized and open source project, we’d like to thank those who have helped out in our community to improve Taiko.\n\n* `HV` for creating a blog post: [What is Taiko? For Beginners](https://mirror.xyz/0x465918b217D2eF4a70ee8983C2C92D2Cfc4347eF/QVf_0otb_MYt9aAkaICjuG9WjjxXh7WVXkDUUjLC-Wg)\n\n* `ex_sxcr` for joining as a moderator and helping answer questions + provide clarity.\n\n* `qukuaizhao` for the good vibes in Discord ❤️.\n\n* Everyone else on the Discord helping to answer questions and promote learning about Ethereum and Taiko.\n\n \n\n","timestamp":"1669351810","title":"Taiko Community Update #2"},"digest":"yZSSixijWKLYos1OaY_IjlanIJ2lVhLPJqDB7t-GIQ8","authorship":{"contributor":"0x5b796c4B197B6DfD413f177059C27963EB80af0F","signingKey":"{\"crv\":\"P-256\",\"ext\":true,\"key_ops\":[\"verify\"],\"kty\":\"EC\",\"x\":\"yO8_glhQHXQ98Uozu7VdJBtRtgmUCiCmypAv3YT8Je4\",\"y\":\"H5lKGo1wDGrJIpdIlfQyQVUE0QfkVnntGl6x-d6KUek\"}","signature":"0xbb7188c782e10bdc38ae92cc78e65eae8a0b21a161ab2331cc4ee77ccf46ea30500b6c6bb2e5c1475d31c2c4b2776c29f8ef4da83c0c40223df2a5e71e8ce9921c","signingKeySignature":"bWmCj-JUuYcZWIMZba7Y9bfVy3N_35NIU__SHZ3Ez6khhqI-GsBmm7x7oTvB-38DxIsz3PFcMUm8ypBqyBWwOg","signingKeyMessage":"I authorize publishing on mirror.xyz from this device using:\n{\"crv\":\"P-256\",\"ext\":true,\"key_ops\":[\"verify\"],\"kty\":\"EC\",\"x\":\"yO8_glhQHXQ98Uozu7VdJBtRtgmUCiCmypAv3YT8Je4\",\"y\":\"H5lKGo1wDGrJIpdIlfQyQVUE0QfkVnntGl6x-d6KUek\"}","algorithm":{"name":"ECDSA","hash":"SHA-256"}},"version":"04-25-2022","wnft":{"chainId":10,"description":"Hey everyone 👋, we want to update you on the progress we’ve made since our last community update.\n","fee":250,"fundingRecipient":"0x5b796c4B197B6DfD413f177059C27963EB80af0F","imageURI":"QmRoweCRkwgZMLCwwvxeDNmiSQn21PCySKbXT7MYX86Nyk","mediaAssetId":290565,"name":"Taiko Community Update #2","nonce":5068761,"owner":"0x5b796c4B197B6DfD413f177059C27963EB80af0F","price":0,"proxyAddress":"0x7f43A377a1EA156956d5f41dD5aA549712167063","renderer":"0x0000000000000000000000000000000000000000","supply":500,"symbol":"TAIKOCOMMUNITYUPDATE2"},"OriginalDigest":"JdMMaBLOtK3Hk_SGZy_c9WFEnn1jDtOpfeXVHxJAtMU"},{"content":{"body":"**Taiko scales Ethereum in a manner that emulates Ethereum as closely as possible - both technically and non-technically. More specifically, Taiko is an Ethereum-equivalent ZK-Rollup, scaling Ethereum by supporting all EVM opcodes in a layer-2 architecture that is decentralized, permissionless, and secure.**\n\nEthereum represents an enormous leap forward in the mechanisms available for human coordination and personal freedom.\n\nAs a global, credibly neutral settlement layer, Ethereum provides strong digital ownership rights, and offers anyone the ability to move value where and when they want. It is the protocol underpinning an internet of value, and not since the internet itself have we witnessed a network where movement is so fluid.\n\nMore than movement, creation of value is equally fluid and unbounded. The creative power of developers deploying their smart contracts and applications to an always-on, always-accessible, borderless computer is remarkable.\n\nTo achieve the above, Ethereum has had to (rightfully) prioritize certain blockchain attributes over others - namely, decentralization and security over scalability. If a public blockchain is not decentralized and secure, then it is not credibly neutral, and thus not attractive to house highly-valuable, highly-critical functions. However, if a public blockchain is not scalable, then large portions of developers, users, and use cases cannot leverage the network, due to prohibitively high transaction fees and low throughput.\n\nTo *fully* achieve the impact of which it is capable, Ethereum must necessarily support anyone who wants to participate. Ethereum must be scalable to the human population. This is where Ethereum looks towards [rollups](https://vitalik.ca/general/2021/01/05/rollup.html) as the most promising scaling solution, and the most promising type of rollup is an Ethereum-equivalent ZK-Rollup.\n\nTaiko aims to be a fully Ethereum-equivalent ZK-Rollup. We aim to scale Ethereum in a manner that emulates Ethereum itself at a technical level, and a principles level.\n\n## Taiko Technical Overview\n\nZK-Rollups scale computation by executing, aggregating, and proving transactions off-chain, and relying on Ethereum for data availability and validity proof verification. The biggest drawback of the currently in-production ZK-Rollups are that they cannot support the generalized computation of the EVM exactly, but instead are mostly application-specific. This breaks compatibility with existing Ethereum L1 smart contracts and dapps, and further, makes it difficult to build new ones that offer the same type of composable, expressive experiences.\n\nEthereum-equivalent ZK-Rollups, sometimes called ZK-EVMs, are the holy grail of layer-2 scaling solutions in that they do not compromise on security or compatibility. In recent parlance, Taiko aims to be a [type-1 ZK-EVM](https://vitalik.ca/general/2022/08/04/zkevm.html), which prioritizes perfect EVM/Ethereum-equivalence over ZK-proof generation speed.\n\nTaiko consists of three main parts: the ZK-EVM circuits (for proof generation), the L2 rollup node (for managing the rollup chain), and the protocol on L1 (for connecting these two parts together for rollup protocol verification).\n\n### 1\\. ZK-EVM\n\nThe ZK-EVM proves the correctness of the EVM computations on the rollup with validity proofs.\n\nTaiko can run Ethereum smart contract code as is, zero changes necessary. Developers can migrate their existing Ethereum smart contracts and full dapps to Taiko trivially, or of course implement their new solidity code on Taiko as their first/only environment. Taiko implements a ZK-EVM that supports every EVM opcode, producing a validity proof of the[ ZK-EVM circuit](https://github.com/privacy-scaling-explorations/zkevm-circuits). Besides perfect compatibility with Ethereum L1 smart contracts and dapps, this also means that all Ethereum and solidity tooling works seamlessly with Taiko, no need to disrupt developers’ workflow whatsoever.\n\nThe result of this is two-fold:\n\n1. Developer experience is exactly what solidity smart contract developers are already used to - no wasted time, no friction. The momentum behind EVM developers and Ethereum smart contracts are unstoppable, and that momentum need not be diverted or slowed.\n\n2. Smart contracts (and systems of smart contracts/dapps) that have been running on Ethereum - in many cases for years, with billions of dollars of value therein - are battle-hardened, and could port over to Taiko without introducing risk of compiling them to a different language, or otherwise tweaking the framework. That means porting over the exact dapps, or the smart contract building blocks/patterns of development.\n\nBeyond the benefits of EVM-equivalence, which mostly manifests itself at the application layer, Taiko aims for Ethereum-equivalence, allowing it to make use of existing Ethereum infrastructure, such as execution clients, easily repurposed as Taiko nodes. For instance, the Taiko client is currently based on the battle-hardened Go-Ethereum client. So, not only is the VM perfectly compatible, but the ‘surrounding tissue’ is as well, given Taiko nodes use the same hashing algorithm, signature scheme, and storage data structure as Ethereum. Importantly, Taiko seeks to be Ethereum-equivalent going forward as well; if there are Ethereum protocol updates, Taiko will implement them in our zkEVM to maintain synchronization. Finally, if Taiko creates compelling new directions from our own R&D, we can work to have them implemented on Ethereum, helping the L1.\n\nIn terms of compatibility, it is not just developers and infrastructure providers that will have a smooth time on the Taiko rollup, but users as well. On Taiko, the user experience, usage patterns, and products will all be completely familiar to users.\n\nIt is worth pausing to reflect on a meta-thought about why the above is so important. As a general purpose L2, Taiko’s goal is to empower builders, who ultimately empower users. **We build what we build so others can do what they do.**\n\n**Taiko will only make a difference in this world if it helps others make a difference in this world.** Harnessing the power of Ethereum, the EVM, the well-defined infrastructure and tools, the critical mass of smart contracts and the tacit knowledge of the developers are the primary reasons to be a type-1 ZK-EVM. This excites us.\n\n### 2\\. Taiko L2 Rollup Node\n\nTaiko nodes get transaction data from Ethereum and execute the transactions on L2, ultimately progressing the state according to the transaction executions. Thus these nodes manage the rollup chain. Currently, the Taiko node is an Ethereum Geth fork.\n\n### 3\\. Taiko Protocol\n\nThe Taiko protocol defines and enforces the rollup rules and defines potential participants. The design upholds the core principles of security, decentralization, and permissionlessness.\n\nSmart contracts deployed on Ethereum L1 act as the data availability mechanism and verifier of the ZK-SNARK proofs. A smart contract deployed on Taiko L2 performs certain important protocol functions we explain in our [whitepaper](https://github.com/taikochain/whitepaper).\n\nIn terms of network participants, we can observe three roles that fit into the above architecture:\n\n1. *Proposers*. Construct rollup blocks from users’ L2 transactions and propose them to L1; any willing participant can perform this block creation function.\n\n2. *Provers*. Generate ZK-SNARK proofs asserting the validity of L2 transactions and blocks out of the aforementioned proposed blocks; any willing participant can perform this proving function.\n\n3. *Node runners*. Execute transactions from on-chain data to stay in sync with the state of the chain. While both Proposers and Provers need to run nodes to fulfill their respective roles, other actors would also run nodes, such as those offering services like a block explorer, and node infrastructure providers. Any willing participant can run Taiko nodes.\n\n**How it works**\n\nBlocks in the Taiko L2 blockchain consist of collections of transactions that are executed sequentially. New blocks can be appended to the chain to update its state, which can be calculated by following the protocol rules for the execution of the transactions.\n\nBlock submission is split into two parts:\n\n1. Block proposal: A block is proposed, with the block data published on Ethereum, and the block appended to the proposed blocks list in the *TaikoL1* contract. The protocol ensures the block is immutable at this point, meaning the block execution is deterministic, and so anyone can calculate the post-execution chain state. We refer to a block and all enclosed transactions at such point as *finalized*. A distinguishable feature in a proposed block on L1 is that there may be invalid transactions that will be skipped over by Taiko L2 nodes. This feature allows for fault-tolerance while multiple blocks are proposed simultaneously.\n\n2. Block verification: Because all proposed blocks are deterministic, blocks can be proven in parallel, since all intermediate states between blocks are known. Once a proof is verified for the block and its correctly-linked parent block is on-chain finalized, we mark the block as *on-chain finalized*.\n\nA fundamental requirement of the protocol is that all data that is necessary to reconstruct the current state, and thus to create and append new blocks, is publicly available on Ethereum. Further, provers can generate proofs for a block using only public data on Ethereum. It is these facts, relying on Ethereum public data and giving all would-be participants a fair playing field, that makes Taiko’s L2 decentralized.\n\nFor in-depth information on the Taiko rollup, please see the [whitepaper](https://github.com/taikochain/whitepaper).\n\nA general truth is that the EVM was not meant to run in a ZK-circuit, and there are plenty of facets of EVM computation and Ethereum data structures and embedded cryptography which are ZK-SNARK-unfriendly and inefficient (slow) to prove. Overcoming these challenges has been the aim of diligent work by many in the field, such as the EF’s PSE. Nonetheless, it remains that generating ZK proofs for EVM computation is slow. This is the main tradeoff opposing compatibility in the different types of ZK-EVMs, with type-1 being slowest with proof generation, but possessing perfect compatibility and future proof-ness. Other types are much faster to generate proofs, but lose differing degrees of EVM/Ethereum-compatibility and future proof-ness.\n\nWhile upholding the non-negotiables of being decentralized, permissionless, and secure - and the priority of complete EVM-equivalence - it is the explicit goal of the Taiko rollup to mitigate the drawbacks of slow proving time via protocol design. That is, the protocol seeks to reach finality quickly, before the ZKPs have been generated. We will continue to design the protocol with such goals in mind, but will also remain open to VM adjustments/optimizations if slow proving drastically degrades user experience of the chain.\n\nWith a brief overview of the technicals complete, let’s move to the human, community aspect of Taiko and Ethereum compatibility. This is extremely important, because after all, blockchains are code-enforced social contracts. It’s ultimately humans and their values-systems that drive the protocols.\n\n## Taiko Tenets\n\nBelow layer-1 is layer-0, the people. Blockchains are built by people, and what these people care about gets baked into the social contract, and into the code and overarching design. As mentioned, here again we seek to have the strongest Ethereum-compatibility.\n\nWe have good reason to stick close to the Ethereum example and specification; it is not solely out of mere love for the protocol and the people. It is because it is the only ecosystem that gives us what we care about, and a shot at changing the world for the better, especially for those who need it most. This sounds lofty, but such are the aims of the Ethereum community, and of Taiko.\n\nBelow we share the Taiko Tenets, three core principles that guide us.\n\n### Accessible\n\nAnyone who wants to use, build on, or participate in Taiko can do so. This is the case because the transaction fees are cheap and throughput is high; the developer experience is robust and Ethereum dapp migration is seamless; the network is permissionless and reuses Ethereum infrastructure to the fullest extent. You can’t have freedom without access.\n\n### Inclusive\n\nTaiko is censorship-resistant and cannot exclude groups or individuals. The rollup is decentralized - relying on Ethereum for data availability and security; and permissionless - allowing any network participant, user, or builder to opt-in. There are no special roles which can censor users/applications/transactions. We are only interested in building credibly neutral, fair systems.\n\n### Open\n\nTaiko is fully open-source and community-centric. We build on the shoulders of giants, and cherish contributing back into Ethereum’s technical progress and community. We value community contributions into the project, harnessing the best minds and ideas that are interested in the space. The type of activity Taiko executes and secures mandates transparency.\n\n## Thank you\n\nThank you for reading. We have been working on Taiko since Q1 2022, with certain teammates contributing to ZK-EVM R&D since 2021, and many more of us working in the scalability and ZK-Rollup space since 2018. We are extremely excited to continue along our journey, as it is our greatest passion and honor to work towards bringing Ethereum to billions of people, securely.\n\nWe’d like to thank many teams and researchers for their phenomenal work on the ZK-EVM and related technologies, including the Ethereum Foundation PSE, Vitalik, Zcash, Aztec, Scroll, and several others.\n\nIn further posts we will go deeper into Taiko’s technical architecture, and share a roadmap with timelines. If you’d like to learn more about Taiko’s rollup protocol right now, you can check out our [whitepaper](https://github.com/taikochain/whitepaper).\n\n## Join us\n\nIf you’d like to join us on our journey in any capacity, we’d love to hear from you. You can apply to join our team by emailing jobs@taiko.xyz, look around and contribute to our [GitHub](https://github.com/taikochain), or join the community via [Discord](https://discord.gg/WqwMUxQEgy), [Twitter](https://twitter.com/taikoxyz), or [Reddit](https://www.reddit.com/r/taiko_xyz/).\n\n\n\n","timestamp":"1665375123","title":"Introduction to Taiko"},"digest":"97qYPn98b84bjYeEMj-V3JfVgZ3_ChqcJGOBepKQiaY","authorship":{"contributor":"0x5b796c4B197B6DfD413f177059C27963EB80af0F","signingKey":"{\"crv\":\"P-256\",\"ext\":true,\"key_ops\":[\"verify\"],\"kty\":\"EC\",\"x\":\"417YNijw0Z5zjDPf2Q9i1IUhgF1yM28_z6QENZ6DdpI\",\"y\":\"_OKtEPfEp1RTmYD5ZlLIL_hd9t1I-ppd8gGmwb5DSrw\"}","signature":"0x719f8ee06a38fdf64a9c94c5708f4e9437aafabda8d6cd83f6d3afd36cee694c3f534e7d07daeead98f51a5eb5b1a0e537d8aa352ed74ff18321e4bf884933271b","signingKeySignature":"pbVGwKYuIYLfAcXWVT9YGCYYTQfvFTjj6MG0Q23gHOfawgF8_lBTY9BrqZuFFW22Bck79u7Wqy3S2M_4Jceo1Q","signingKeyMessage":"I authorize publishing on mirror.xyz from this device using:\n{\"crv\":\"P-256\",\"ext\":true,\"key_ops\":[\"verify\"],\"kty\":\"EC\",\"x\":\"417YNijw0Z5zjDPf2Q9i1IUhgF1yM28_z6QENZ6DdpI\",\"y\":\"_OKtEPfEp1RTmYD5ZlLIL_hd9t1I-ppd8gGmwb5DSrw\"}","algorithm":{"name":"ECDSA","hash":"SHA-256"}},"version":"04-25-2022","wnft":{"chainId":10,"description":"As a type-1 ZK-Rollup, Taiko scales Ethereum in a manner that emulates Ethereum as closely as possible. Learn more about our design in this post.","fee":250,"fundingRecipient":"0x5b796c4B197B6DfD413f177059C27963EB80af0F","imageURI":"bafybeicyqzrlym773jj3i63vc64v2e676d22xnfvytnsat2vcbqjawy3ny","mediaAssetId":235465,"name":"Introduction to Taiko","nonce":8577684,"owner":"0x5b796c4B197B6DfD413f177059C27963EB80af0F","price":0,"proxyAddress":"0x1374F2B5A51334FA0958Db9eA215CCDAE3c967F4","renderer":"0x0000000000000000000000000000000000000000","supply":500,"symbol":"INTRODUCTIONTOTAIKO"},"OriginalDigest":"oRy3ZZ_4-6IEQcuLCMMlxvdH6E-T3_H7UwYVzGDsgf4"},{"content":{"body":"> *This blog post was authored by [d1onys1us](https://twitter.com/indraynor). Follow me on Twitter pl0x.*\n\nTaiko is fully open source -- you can view all the code on [our GitHub](https://github.com/taikoxyz).\n\nBy \"open source\" we mean free to see the source and modify it. Specifically, we use the permissive MIT license for all of our code except our minimally modified geth fork, where we maintain the original GPL license.\n\nHere is a summary of the code powering Taiko:\n\n* Protocol smart contracts\n\n * [taikoxyz/taiko-mono](https://github.com/taikoxyz/taiko-mono): MIT\n\n* L2 node software\n\n * [taikoxyz/taiko-client](https://github.com/taikoxyz/taiko-client): MIT\n\n * [taikoxyz/taiko-geth](https://github.com/taikoxyz/taiko-geth): GPL\n\n* ZK-EVM circuits\n\n * [privacy-scaling-explorations/zkevm-circuits](https://github.com/privacy-scaling-explorations/zkevm-circuits): MIT or Apache 2.0\n\nIn summary, the entire network is open source and unrestricted to join in and participate: the L2 nodes, proposers, provers, and smart contracts on L1/L2.\n\n# MIT vs. GPL\n\nBy GPL, we'll mean GPLv3 for the sake of example, but there are other variants such as AGPLv3, GPLv2, and LGPL -- GPL is more nuanced, as you can see.\n\nThe primary difference between MIT and the GPL is that MIT essentially allows you to do whatever you want, as long as you retain the copyright and permission notice in the codebase. The GPL license imposes a few more restrictions on the developers. For example, using a GPL library in your codebase requires you to convert your entire project under the GPL license, which makes it a \"viral\" license. It also means that you can't create a modified proprietary version.\n\nWhile GPL can be annoying for developers and companies, the idea is that it is nice for users; it gives them the freedom to view the source code. It also prevents someone from running [a modified and possibly malicious version](https://dev.to/ender_minyard/why-i-no-longer-use-the-mit-license-for-new-projects-348m) of the codebase. So this is another way GPL protects the user. GPL, in general, is more concerned with user freedom than the ease of developers using the software.\n\n# Why we went the permissive route\n\nTaiko's guiding principles are:\n\n* Accessible\n\n* Inclusive\n\n* Open\n\nLike all things, these licenses make tradeoffs. For example, someone can convert MIT-licensed code to proprietary code with (potentially malicious) patches. That is a real potential risk for users. On the other hand, GPL-licensed code can exclude developers who don't want to relicense their entire project to GPL just to use a code snippet.\n\nThe reason we chose MIT on this tradeoff was for a similar reason we decided to be a Type 1 ZK-EVM: compatibility and simplicity.\n\nThe MIT license will make it much easier for other people to use our codebase and increases the opportunity for collaboration, which is a part of our DNA. It's also inclusive because it's so short and straightforward. It's easy to understand that you can freely use this code however you want as long as you include the license.\n\n# About user freedom\n\nTo make a final note about GPL, a somewhat controversial license. One could use GPL, specifically the AGPL, in an unethical manner (like making it scary to use and selling another license). It is also undoubtedly more difficult to integrate from the developer's perspective. However, it's always nice to think about one core principle often mentioned by the [Free Software Foundation](https://www.fsf.org/): user freedom.\n\nGiven recent events, we, as developers, must continue thinking about our responsibility to the user. Especially how we should always make it easy for the user to understand and verify our software.\n\nHistorically, some of the worst events have occurred due to a lack of transparency. Therefore, we should strongly encourage openness for the sake of our beloved users. And remember: don't trust, verify.\n\n# Collaborate with us\n\nOkay, so we're all open-source; that's great. Now you want to know how you can contribute. Our [Contributing guide](https://github.com/taikoxyz/taiko-mono/blob/main/CONTRIBUTING.md) is a living document you can reference. It will improve over time.\n\nFor now, here are some specific places to start:\n\n* Reviewing our protocol and offering suggestions on our [GitHub Discussions](https://github.com/taikoxyz/taiko-mono/discussions) or other social platforms.\n\n* Writing educative material for the community to learn more about Taiko and ZK-EVMs.\n\n* Opening issues, we have [templates](https://github.com/taikoxyz/taiko-mono/issues/new/choose) for Bug Reports and Feature Requests.\n\n* Taking on issues, you can find some with the label `good first issue` [here](https://github.com/taikoxyz/taiko-mono/labels/good%20first%20issue).\n\nAny contributor will be featured as a contributor on our README, and be eligible for the 2022 Taiko Contributor (Founding Year) GitPOAP 😎.\n\nThanks for reading!\n\n# Follow us\n\n* Website: [https://taiko.xyz](https://taiko.xyz/)\n\n* Discord: \n\n* GitHub: \n\n* Twitter: \n\n* 🥁 Join us 🍗: ","timestamp":"1669933221","title":"Taiko is fully open source"},"digest":"yBCa4zKyXz2lNeeoq9oz-NGlp1So-Fv4Gu0CVkp38uQ","authorship":{"contributor":"0x2b1F13149C7F89622BBfB46Ae1e3ECc573Bb9331","signingKey":"{\"crv\":\"P-256\",\"ext\":true,\"key_ops\":[\"verify\"],\"kty\":\"EC\",\"x\":\"HA2ZeLg0lRobJHRdlR8czM8AM9LMpqyITWkPE1pLAfk\",\"y\":\"UZ7neopFenRB5_MnTbpxeQ_1nBMowb-4wP29Kzr6ha4\"}","signature":"0x06bef07adaa4cee886c6772fb36591c616ff5f6ee07f2d99e08850d283f4ab8413596d1580dda2fb00144fb8cfbbf6b37dcf2fdcf54ea5baa76db9773014c1f21c","signingKeySignature":"_bV4CgKVZnYvaJ_yXVn8ZXgzzmPiaZH7FpY-mdI2ppd6ntXU8-8BBnvT-1RJ3RSFo0rndV0OWuO1cT6kVqyZKw","signingKeyMessage":"I authorize publishing on mirror.xyz from this device using:\n{\"crv\":\"P-256\",\"ext\":true,\"key_ops\":[\"verify\"],\"kty\":\"EC\",\"x\":\"HA2ZeLg0lRobJHRdlR8czM8AM9LMpqyITWkPE1pLAfk\",\"y\":\"UZ7neopFenRB5_MnTbpxeQ_1nBMowb-4wP29Kzr6ha4\"}","algorithm":{"name":"ECDSA","hash":"SHA-256"}},"version":"04-25-2022","wnft":{"chainId":10,"description":"Taiko is fully open source -- you can view all the code on our GitHub.\n\nBy \"open source\" we mean free to see the source and modify it.","fee":250,"fundingRecipient":"0x5b796c4B197B6DfD413f177059C27963EB80af0F","imageURI":"QmUzJLXqxyq4StZoYfxfqLxU1kLdN3yJfphqXignD24Yd8","mediaAssetId":298408,"name":"Taiko is fully open source","nonce":349407,"owner":"0x2b1F13149C7F89622BBfB46Ae1e3ECc573Bb9331","price":0,"proxyAddress":"0xD7BB89c0eC6AC6a0Ec4E5A8a0B32f8bDF299409e","renderer":"0x0000000000000000000000000000000000000000","supply":500,"symbol":"TAIKOISFULLYOPENSOURCE"},"OriginalDigest":"31vzkwgNaKNrze0oIv_wTKCw6Tha8OYQ6ffrquS3XUg"},{"content":{"body":"Today, the Taiko Alpha-1 testnet (a1) is live - our first public testnet! We’ve codenamed this testnet, **Snæfellsjökull**. Be on the lookout for other Icelandic volcano releases as we approach mainnet over 2023! 🌋 \n\nWe’re thrilled to reach this milestone towards our Type-1 ZK-EVM, with the ultimate goal of scaling Ethereum in a manner that is as secure and seamless for developers and users as possible. We still have a long way to go, but we hope you will join us in using and testing our first public testnet release.\n\nIf you want to jump right in, you can head to the testnet guide here: \n\n\n\nIf you want to learn more about what is in this release, and what is not, read on.\n\n![https://taiko.xyz/docs/category/alpha-1-testnet-guide](https://images.mirror-media.xyz/publication-images/W0LFjBfCqJdV7VA_duPVb.jpg?height=1832&width=2752)\n\nTaiko has been committed to building in the open, and our [GitHub](https://github.com/taikoxyz) has reflected this for some time with everything being open source. In that vein, this first public testnet is as open as we can make it. It is open to all developers to deploy contracts on, all users to test out, and all willing participants to run an L2 node and propose blocks.\n\n## About the Taiko Alpha-1 testnet (Snæfellsjökull)\n\n* **Open to all developers** to [deploy smart contracts](https://taiko.xyz/docs/alpha-1-testnet/deploy-a-contract). As Taiko aims to be a type-1 ZK-EVM (Ethereum-equivalent), you can use all the Ethereum/solidity tooling you know and love.\n\n* **Open to all users** who want to use it and play around with some transactions.\n\n* **Open to all interested parties** to [run an L2 node](https://taiko.xyz/docs/alpha-1-testnet/run-a-node), including as a proposer! Taiko will be running some nodes and proposing blocks, and we hope you will join us.\n\n* The L1 environment is a private Ethereum PoA fork that Taiko runs (testnet L1).\n\n* Faucet for requesting ETH and a sample ERC20 token on Taiko testnet [L2](https://l2faucet.a1.taiko.xyz/) and [L1](https://l1faucet.a1.taiko.xyz/).\n\n* [Bridge](https://bridge.a1.taiko.xyz/) to move assets between testnet L2 and L1.\n\n* Block explorers to view assets and activity on testnet [L2](https://l2explorer.a1.taiko.xyz/) and [L1](https://l1explorer.a1.taiko.xyz/).\n\n## What is not in this testnet\n\n* Ability to become a prover. You cannot extend your node into a prover. \n\n* Validity proofs. There will be no ZKPs generated in this testnet release.\n\n* Pre-deployed dapps. Bridging between L2 and L1 and transferring ETH or ERC20 to friends are the only supported user actions out-of-the-box. Any developer can deploy their smart contract or dapp, though, making it available to all users.\n\n## Get involved\n\nOnce more, here is the testnet guide where you can find documentation and links to all relevant apps/tools for testnet usage:\n\n\n\nBesides deploying, using, and running, there are plenty of other ways you can get involved and help Taiko improve. Some of these include:\n\n* [Provide feedback](https://github.com/orgs/taikoxyz/discussions/new?category=feedback&title=Testnet%20feedback%20form&body=%23+Friction+log%0D%0A-+TODO%0D%0A%0D%0A%23+Other+notes%0D%0A-+TODO%0D%0A) on any bugs or friction you come across, or anything you find may be helpful.\n\n* Create tutorials or other content that can help developers and users get started.\n\nHearing from you all is the reason we have been keen to release this testnet as early as possible. On that note, we will have our **first-ever community call on Thursday, December 29th at 15:00 UTC on our Discord server**. You can find the call channel [here](https://discord.gg/taikoxyz?event=1057323602678124576) and signal your interest to join. We will be providing general updates, but also invite questions in AMA style. Please ask any questions you would like in the “community-call-questions” [Discord](https://discord.gg/taikoxyz) channel in advance.\n\nWe also want to commemorate this moment on Snæfellsjökull with all of you 🙂. As a result, we will be minting a POAP for all users of the testnet prior to January 31st 23:59 UTC. Any user with a bridging transaction + one other type of transaction (transfer, dapp tx) will receive one. They will be issued in the month of February.\n\n## Thank you\n\nFinally, we want to say a sincere thank you. We have tons of people to thank, as this journey has been a year in the making or longer for some. We will specifically thank the Ethereum Foundation’s Privacy & Scaling Exploration team for their ZK-EVM work, along with all contributors to that effort. We thank the incredible Taiko community and our early supporters who have contributed from the beginning, and of course the broader Ethereum community who have done the same.\n\n### Join us\n\nExplore open positions on our [job board](https://www.notion.so/Taiko-Jobs-828fd7232d2c4150a11e10c8baa910a2).\n\n### Follow us\n\nTo stay updated on the latest from Taiko:\n\n* Website: [https://taiko.xyz](https://taiko.xyz/)\n\n* Discord: \n\n* GitHub: \n\n* Reddit: \n\n* Twitter: \n\n### Contribute\n\nContribute to Taiko and earn a GitPOAP! You will also be featured as a contributor on our README. Get started with the [contributing guide](https://github.com/taikoxyz/taiko-mono/blob/main/CONTRIBUTING.md).","timestamp":"1672160691","title":"Taiko Alpha-1 Testnet is Live"},"digest":"du92fke7V7XDdgHqbG1Dhytzn2XhwG408dR78CN1POI","authorship":{"contributor":"0x381636D0E4eD0fa6aCF07D8fd821909Fb63c0d10","signingKey":"{\"crv\":\"P-256\",\"ext\":true,\"key_ops\":[\"verify\"],\"kty\":\"EC\",\"x\":\"4zcQdnWNxHeBOOkRLGozl2oI_rBZTg8bVaZ2Xq8sbN8\",\"y\":\"U31TF_BfLJEX_XcNt7KIjaZDA8p7AHVPq98KRKlPo9k\"}","signature":"0xb33f23c84df31b4e60e24957fa51e2af571b008e75d57f8064ddbaed204f248573f2433feaa93d2a13756d1b8b8123ffb836b949c53e79aad462745aef125a621c","signingKeySignature":"EEvOuH-jYBd2YuJGDbSWuPZFks-kqf7U0LleZdkwUQ7JuZQE7qDyFf5NTNWKFu_5qqbhVTh96Q9IX9wodE_y4g","signingKeyMessage":"I authorize publishing on mirror.xyz from this device using:\n{\"crv\":\"P-256\",\"ext\":true,\"key_ops\":[\"verify\"],\"kty\":\"EC\",\"x\":\"4zcQdnWNxHeBOOkRLGozl2oI_rBZTg8bVaZ2Xq8sbN8\",\"y\":\"U31TF_BfLJEX_XcNt7KIjaZDA8p7AHVPq98KRKlPo9k\"}","algorithm":{"name":"ECDSA","hash":"SHA-256"}},"version":"04-25-2022","wnft":{"chainId":10,"description":"Today, the Taiko Alpha-1 testnet (a1) is live - our first public testnet! We’ve codenamed this testnet, Snæfellsjökull. Be on the lookout for other Icelandic volcano releases as we approach mainnet over 2023! 🌋\n","fee":250,"fundingRecipient":"0x5b796c4B197B6DfD413f177059C27963EB80af0F","imageURI":"QmTKWBRvETAS5Mr7rvMwyDRNbtGc161sv99wyDmQF8EG1N","mediaAssetId":328375,"name":"Taiko Alpha-1 Testnet is Live","nonce":7690614,"owner":"0x381636D0E4eD0fa6aCF07D8fd821909Fb63c0d10","price":0,"proxyAddress":"0xf0847b3B3EffD493D50e0388FF55D76300732cc9","renderer":"0x0000000000000000000000000000000000000000","supply":500,"symbol":"TAIKOALPHA-1TESTNETISLIVE"},"OriginalDigest":"-lahy4KbGkeAcqhs0ETG3Up3oTVzZ0wLoE1eK_ao5h4"},{"content":{"body":"Ethereum has come a long way in its seven-year life — changing the world, in our opinion — but it is only just getting started.\n\nScaling Ethereum at a technical level, as ZK-EVMs aim to do, is just one (huge) part of the equation in bringing it to the world - there is also the need to… actually bring it to the world!\n\nThat’s why we are initiating the **Taiko Ambassador Program**.\n\nWe need help in spreading the word that Ethereum scales securely and that you can use your existing solidity code, dapp, toolchain, or product with an Ethereum-equivalent ZK-Rollup. If you are interested in joining us in this effort, we welcome your participation.\n\n## You can fulfill one or several functions:\n\n* Developer advocacy and relations\n\n* Educational content creator\n\n* Community organizer \n\nSome ambassadors may focus strictly on developer goals, some on community awareness, some on a mix.\n\n> The mandate of the ambassador is to assist, advocate, and educate within the community of Ethereum/Taiko developers and users. Given this is the first iteration of the program, you may help shape the program as much as you participate in it.\n\n## You should consider applying if:\n\n* You are a developer or researcher experienced or interested in Ethereum and ZKPs, and have the ability and desire to teach, communicate, and facilitate the experience of other developers.\n\n* You are not a developer or researcher, but have a strong understanding of Ethereum and ZKPs, and an aptitude for educating people and/or community organization.\n\n* You are a clear communicator, possess patience, and have a strong desire to move the needle on whatever you participate in.\n\n## You can expect the following from the program:\n\n* Ability to work closely with the team and community to achieve the above-articulated goals\n\n* Monthly rewards\n\n* Ability to progress to a full-time role within Taiko Labs\n\n## Apply here\n\n🥁 Here is the application form: 🥁\n\nApplications will remain open until **Friday, January 13, 23:59 UTC**. We will seek to onboard approximately 2 to 4 ambassadors in this first cohort and will re-open the program again once we have some feedback and more capacity.\n\nThank you in advance for your interest in helping scale Ethereum and Taiko, we look forward to welcoming you!\n\n### Join us\n\nExplore open positions on our [job board](https://www.notion.so/Taiko-Jobs-828fd7232d2c4150a11e10c8baa910a2).\n\n### Follow us\n\nTo stay updated on the latest from Taiko:\n\n* Website: [https://taiko.xyz](https://taiko.xyz/)\n\n* Discord: \n\n* GitHub: \n\n* Reddit: \n\n* Twitter: \n\n### Contribute\n\nContribute to Taiko and earn a GitPOAP! You will also be featured as a contributor on our README. Get started with the [contributing guide](https://github.com/taikoxyz/taiko-mono/blob/main/CONTRIBUTING.md).","timestamp":"1672862542","title":"Taiko Ambassador Program"},"digest":"weGZlAWcC741tTvAnGXGQt9Ep2Rkgl6LITpJ3IomBII","authorship":{"contributor":"0x381636D0E4eD0fa6aCF07D8fd821909Fb63c0d10","signingKey":"{\"crv\":\"P-256\",\"ext\":true,\"key_ops\":[\"verify\"],\"kty\":\"EC\",\"x\":\"0iMX67LQd6Qb7GP9n3SZ1-65HExs3_B31V9iMmD4ToY\",\"y\":\"LZJ_7eeo-lETUES8GabDJOa9VdDaCBFmrIbMwvw-QFo\"}","signature":"0x1294f77d45afcb00255721849b937e76f376d689db5fd1a059fcbf3c29c1e74057e35aeac789c7639405cac3007638d694cf42610c19907889da636d45dc8c4d1c","signingKeySignature":"BHjFcB26pc1W9z9r9S0isQEzMAMr2m_RLZB-sc-drDe23SL9dnchLSbAYKgrcAsZhc-2sPb4wHhcfAbrpEF3Tw","signingKeyMessage":"I authorize publishing on mirror.xyz from this device using:\n{\"crv\":\"P-256\",\"ext\":true,\"key_ops\":[\"verify\"],\"kty\":\"EC\",\"x\":\"0iMX67LQd6Qb7GP9n3SZ1-65HExs3_B31V9iMmD4ToY\",\"y\":\"LZJ_7eeo-lETUES8GabDJOa9VdDaCBFmrIbMwvw-QFo\"}","algorithm":{"name":"ECDSA","hash":"SHA-256"}},"version":"04-25-2022","wnft":{"chainId":10,"description":"Ethereum has come a long way in its seven-year life — changing the world, in our opinion — but it is only just getting started.\n","fee":250,"fundingRecipient":"0x5b796c4B197B6DfD413f177059C27963EB80af0F","imageURI":"QmcM2j9R4R6CCJhgp9FBQpQL65ySf4L73HZpNZEmgH7B5Z","mediaAssetId":336972,"name":"Taiko Ambassador Program","nonce":9848835,"owner":"0x381636D0E4eD0fa6aCF07D8fd821909Fb63c0d10","price":0,"proxyAddress":"0x55683134E85eaf3abDaF7B57347ED2e77668804d","renderer":"0x0000000000000000000000000000000000000000","supply":500,"symbol":"TAIKOAMBASSADORPROGRAM"},"OriginalDigest":"BvcEyYeVIiHnjc-i5qf3zR4s67Jc6nz_R6OSGj5rzOE"},{"content":{"body":"Taiko is building a Type 1 (Ethereum-equivalent) ZK-EVM. What benefits come from using a Type 1 ZK-EVM? To answer this, we need to understand the changes a ZK-EVM can make at various levels and the tradeoffs they incur. Let’s learn together.\n\nThis post makes a few assumptions about your understanding of Ethereum. We are going to suggest that you first understand the following:\n\n* What a [ZK-EVM](https://ethereum.org/en/developers/docs/scaling/zk-rollups/) (EVM-compatible ZK-Rollup) is at a high level\n\n* How Ethereum stores data in the form of a [Merkle Patricia Tree](https://ethereum.org/en/developers/docs/data-structures-and-encoding/patricia-merkle-trie/) and uses Merkle proofs\n\n* How smart contracts price their execution with a [concept of gas](https://ethereum.org/en/developers/docs/gas/)\n\n* The [different types of ZK-EVMs](https://vitalik.ca/general/2022/08/04/zkevm.html)\n\nWith that out of the way, here are the five questions we’ll be exploring:\n\n* [What is a Type 1 ZK-EVM?](https://www.notion.so/The-Type-1-ZK-EVM-82b1886f4cc44061bc35b1d54d4a52da)\n\n* [What does a Type 2+ ZK-EVM change?](https://www.notion.so/The-Type-1-ZK-EVM-82b1886f4cc44061bc35b1d54d4a52da)\n\n* [What are the impacts of these changes?](https://www.notion.so/The-Type-1-ZK-EVM-82b1886f4cc44061bc35b1d54d4a52da)\n\n* [Why does proof generation cost matter?](https://www.notion.so/The-Type-1-ZK-EVM-82b1886f4cc44061bc35b1d54d4a52da)\n\n* [Why use a Type 1 ZK-EVM?](https://www.notion.so/The-Type-1-ZK-EVM-82b1886f4cc44061bc35b1d54d4a52da)\n\n## What is a Type 1 ZK-EVM?\n\nOne way to think of the different types of ZK-EVMs is by their proximity to Ethereum’s architecture at the base layer, such as:\n\n* The usage of a Merkle Patricia Tree for the [various state trees](https://medium.com/@eiki1212/ethereum-state-trie-architecture-explained-a30237009d4e)\n\n* The [execution client specification](https://ethereum.org/en/developers/docs/nodes-and-clients/)\n\n* The [amount of gas each opcode uses](https://ethereum.org/en/developers/docs/evm/opcodes/)\n\n![Adapted from https://vitalik.ca/general/2022/08/04/zkevm.htmled from ](https://i.imgur.com/4e3Dvgx.png)\n\nThe different types of ZK-EVMs make tradeoffs between compatibility and proof generation cost. A Type 1 ZK-EVM prioritizes compatibility over proof generation cost.\n\nAnother term for Type 1 ZK-EVMs is “Ethereum-equivalent”. This term comes from the fact that Type 1 ZK-EVMs make no changes to the Ethereum architecture, whether it be the hash function, state trees, or gas costs. This equivalency allows us to reuse execution clients with minimal modification.\n\n## What does a Type 2+ ZK-EVM change?\n\nIn this post, when we say Type 2+, we are referring to Type 2/2.5 ZK-EVMs. Type 3/4 ZK-EVMs are [not quite EVM-equivalent](https://vitalik.ca/general/2022/08/04/zkevm.html), so we’ll put them aside for the discussions of this post.\n\nType 2+ ZK-EVMs change parts of the Ethereum stack which are complex to prove. The changes might include:\n\n* Changing gas costs for ZK-unfriendly operations\n\n* Changing the Keccak hash function to a more ZK-friendly one\n\nThese changes result in lower proof generation costs while maintaining bytecode level compatibility, but they could also have some other impacts.\n\n## What are the impacts of these changes?\n\nLet’s break this down via examples to paint a clearer picture of how these changes could impact you as a smart contract developer.\n\n### 1\\. Security mechanisms could change\n\nA classic example of using [gas as a security mechanism](https://consensys.net/diligence/blog/2018/12/silent-but-vulnerable-ethereum-gas-security-concerns/) is setting a fixed gas limit for an ETH transfer so that state changes are not possible in the destination address. Smart contracts that rely on this for security will no longer be secure if gas costs are changed, which would allow state changes to occur. Another scenario arises if Keccak hashes get super expensive, and the security of the smart contract depends on a minimum number of hashes to be possible (like for a fraud-proof).\n\n### 2\\. Changing gas costs could have side effects\n\nIf your smart contract is optimized for gas costs as specified on Ethereum L1, changing these gas costs could cause the contract to use more gas than intended. You also might be using [tools to fine-tune the gas usage](https://github.com/cgewecke/hardhat-gas-reporter) in your contract, and changing gas costs could break those tools. Additionally, increasing gas costs could cause the contract to exceed the block gas limit. For example, if the contract frequently uses the Keccak opcode, the developer might need to find more gas-efficient ways to get things done or change the hash function.\n\n### 3\\. Changing the block hash could have side effects\n\nA Type 2+ ZK-EVM might use a different hash function — and produce different state roots. This change could break compatibility for smart contracts that rely on the block hash. For example, a bridge contract might [use a Merkle proof for verification](https://eips.ethereum.org/EIPS/eip-1186), and changing the hash function from Keccak to something else would break these proofs. Relying on the block hash this way would also break with the introduction of Verkle trees. Hopefully, we can have an abstracted precompile to use in the future.\n\n### You could lose some nice features of Keccak\n\nThe [Keccak hash function](https://academy.binance.com/en/glossary/keccak) is widely accepted as a battle-tested and secure hash function, so changing it for an alternative could be risky. Additionally, Keccak has much faster native performance and lower gas fees when compared to some more ZK-friendly hash functions, such as [Poseidon](https://www.poseidon-hash.info/).\n\n## Why does proof generation cost matter?\n\nA higher proof generation cost can be seen as a negative for a few reasons:\n\n* A potentially longer time to finality\n\n* Imbalances the ratio between gas cost and proof generation cost\n\n* More expensive transactions\n\nWe are not concerned about the longer time to finality because we achieve instant finality through our protocol design, by circumventing the need to wait for a proof when on the rollup (proposed blocks have the same finality as the enclosing Ethereum L1 block, see: [Layer 2 Finality](https://hackmd.io/@taikolabs/HkN7GR64i#/)). In the case where a proof is needed, such as moving assets to another layer, we are optimistic about [new methods for bridging that don’t require a full proof](https://twitter.com/VitalikButerin/status/1588708049359089664?s=20&t=OZpu9KpHJQDWGu_X2MnXxw).\n\nThe ratio between gas cost and proof generation cost matters because a malicious actor could submit blocks that are cheap in gas but expensive to generate a proof for (DOS attack). Mitigating this attack vector is a more extended topic, so we’ll go deeper into our proposed solution in a subsequent post.\n\nIn general, we are looking forward to future improvements in proof generation costs, which will decrease the cost of transactions:\n\n* Prover-level optimizations like [Hyperplonk](https://www.espressosys.com/blog/hyperplonk-a-zk-proof-system-for-zkevms) and [Caulk](https://eprint.iacr.org/2022/621.pdf)\n\n* [General optimizations & tricks](https://docs.google.com/presentation/d/1eHVzLPRIEziCJ_oDuJG0yZ-5klNj_daqioC0UaGDaiw/edit?usp=sharing)\n\n* [Community focus toward a fully SNARKed Ethereum](https://twitter.com/VitalikButerin/status/1588669782471368704?s=20&t=nMFRL5j5Ffal66NMtJ_6KA)\n\n* ZKP-specific hardware\n\n## Why use a Type 1 ZK-EVM?\n\nThe main advantage of using a Type 1 ZK-EVM is that you can give it a try without any upfront costs — you don’t need to make any changes to your code or development environment. You can prototype, develop, test, audit, and deploy on Ethereum L1 first and migrate to Taiko later. Alternatively, you can develop on Taiko and then migrate to L1 or another EVM-equivalent chain at any time.\n\nA Type 1 ZK-EVM is a continual development process. It means not only being Ethereum-equivalent now but continuing to inherit future Ethereum upgrades. Staying Type 1 restrains us from adding features that would break our Ethereum-equivalence. It also encourages us to contribute upstream improvements to Ethereum L1.\n\nThank you for reading! 🥁\n\n## Links\n\n* Website (with whitepaper): \n\n* Discord: \n\n* GitHub: \n\n* Twitter: \n\n* Join us: [https://taikochain.notion.site/Taiko-Jobs-828fd7232d2c4150a11e10c8baa910a2](https://www.notion.so/Taiko-Jobs-828fd7232d2c4150a11e10c8baa910a2)\n\n## Sources\n\n* \n\n* \n\n* \n\n* \n\n* \n\n* \n\n* \n\n* [h](https://ethereum.org/en/developers/docs/data-structures-and-encoding/patricia-merkle-trie/)[ttps://medium.com/@eiki1212/ethereum-state-trie-architecture-explained-a30237009d4e](https://medium.com/@eiki1212/ethereum-state-trie-architecture-explained-a30237009d4e)\n\n* \n\n* ","timestamp":"1668488929","title":"The Type 1 ZK-EVM"},"digest":"NYZmLd1IDnfDtmDgswgncq6OZdQ_enKOqG-Fx-8qvBs","authorship":{"contributor":"0x5b796c4B197B6DfD413f177059C27963EB80af0F","signingKey":"{\"crv\":\"P-256\",\"ext\":true,\"key_ops\":[\"verify\"],\"kty\":\"EC\",\"x\":\"LjnohJiDajcEHC7X2CCVVF_AZ0C5BXROU-_c0BX0W2E\",\"y\":\"5GXvglTR44CtJxjys2BipccOAm-tZ9jwFXVkuMDJHbI\"}","signature":"0x4f0c4d1fdbd2e2adc247b91603f6bb0fa4198af82a7e9c56cde27224796b69602e30325bde92ca548289160db43ae74ba2f53d3cf0f1bb562a89403709bc34af1c","signingKeySignature":"FY1OhIn2pRb6ezJCs4oQYrrXNXLWV4uTA4qYPdUjHxU3D64yhTz0Vz6cbkk5CAjVvDWx3mCknfOK0flucz0Rrw","signingKeyMessage":"I authorize publishing on mirror.xyz from this device using:\n{\"crv\":\"P-256\",\"ext\":true,\"key_ops\":[\"verify\"],\"kty\":\"EC\",\"x\":\"LjnohJiDajcEHC7X2CCVVF_AZ0C5BXROU-_c0BX0W2E\",\"y\":\"5GXvglTR44CtJxjys2BipccOAm-tZ9jwFXVkuMDJHbI\"}","algorithm":{"name":"ECDSA","hash":"SHA-256"}},"version":"04-25-2022","wnft":{"chainId":10,"description":"Taiko is building a Type 1 (Ethereum-equivalent) ZK-EVM. What benefits come from using a Type 1 ZK-EVM? To answer this, we need to understand the changes a ZK-EVM can make at various levels and the tradeoffs they incur. Let’s learn together.\n","fee":250,"fundingRecipient":"0x5b796c4B197B6DfD413f177059C27963EB80af0F","imageURI":"bafybeie74reb3nc2w7xawlcczmaiih3op6oxtyf4ygibqmjkxbsrsw7jhi","mediaAssetId":279205,"name":"The Type 1 ZK-EVM","nonce":8051681,"owner":"0x5b796c4B197B6DfD413f177059C27963EB80af0F","price":0,"proxyAddress":"0x8AD8968e2f1E929B3c1571361BC074c5d7efb15E","renderer":"0x0000000000000000000000000000000000000000","supply":500,"symbol":"THETYPE1ZK-EVM"},"OriginalDigest":"w7NSKDeKfJoEy0p89I9feixKfdK-20JgWF9HZzxfeBo"},{"content":{"body":"Below is our brief summary of what happened in the fourth quarter of 2022. It was a super busy one to close out the year, and now we are excited to be writing from 2023 - the year where ZK-EVMs are sure to leave an indelible mark on Ethereum and the world. Let’s jump right in.\n\n## Research & Development\n\n### ZK-EVM\n\n* Implemented RETURNDATASIZE/RETURNDATACOPY.\n\n* Added circuit benchmarks.\n\n* Added unit tests for math gadgets/super circuit.\n\n* Added support for invalid transactions.\n\n* Refactored math gadgets.\n\n* Made improvements to MPT circuit.\n\n* Investigated caulk, hyperplonk and plonky2.\n\n### Client & Testnet\n\n* Created `simple-taiko-node` for running a Taiko node with a simple command, inspired by `simple-optimism-node`.\n\n* Created a guide documenting how to use the testnet.\n\n* Launched faucets and block explorers for interacting with the testnet.\n\n### Bridge\n\n* Implemented a functional bridge relayer in Go.\n\n* Implemented a web UI to integrate with the relayer and bridge smart contracts.\n\n### Protocol\n\n* Fixed a bug in the Bridge contract that allows anyone to disable destination chains.\n\n* Fixed a bug in `getProposedBlock` with boundary checks.\n\n* Refactored the Bridge contract to persist the message status in known storage slots for easier generation of Merkle proofs.\n\n* Exposed more data from the core protocol such as `getUncleProofDelay`, `getBlockProvers`, and `getLatestSyncedHeader`.\n\n* Merged the first tokenomics implementation into the core protocol.\n\n* Forced invalidBlock to have the latest verified block as the parent and also force the transactor to be the golden touch address with 0 gas-price.\n\n* Fixed a bug in TokenVault contract with respect to `msg.value`.\n\n* Changed the core protocol rules to allow empty blocks (blocks with only an anchor transaction).\n\n* Add a Failed Bridge message status to allow future token releasing from the source bridge contract.\n\n* To increase readability, we now call a block “verified” when it is actually finalized on chain. Previous the status is called “finalized” which is confusing sometimes.\n\n* Removed proposer and prover whitelisting from the core protocol implementation to enable the next fully permissionless testnet.\n\n* Moved away from *yarn* and adopted *pnpm*\n\n* Introduced a lot of small improvements on the core protocol implementation.\n\n> All of the above is open source. To learn more or contribute, please visit our [GitHub](https://github.com/taikoxyz).\n\n## Operations & Community\n\nWe [launched our Alpha-1 public testnet, Snæfellsjökull](https://mirror.xyz/labs.taiko.eth/-lahy4KbGkeAcqhs0ETG3Up3oTVzZ0wLoE1eK_ao5h4). The launch happened in late December and participation was several times greater than expected — across all metrics. The testnet was open to all developers to deploy contracts; all users to bridge and perform other transactions; and all willing participants to run an L2 node and act as a proposer. A huge thank you to all who helped test it and make it a smashing success.\n\n![](https://images.mirror-media.xyz/publication-images/MyZWBeL6rbxcBfGiR9w_s.png?height=1974&width=2834)\n\nWe will share many stats about the testnet closer to its end, but for now we’d like to highlight that over 2000 proposers have proposed L2 blocks! Thank you.\n\n### Community grew significantly\n\nThe community grew throughout the quarter, with a big growth spurt in December around the testnet. Our [Twitter](https://twitter.com/taikoxyz) following has reached over 25K, and our [Discord](https://discord.gg/taikoxyz) has reached over 30K members! Welcome, new folks! 👋\n\nTo keep up with the growth of the lively and incredible community, we onboarded new moderators in Discord. Shout out and much love to ex_scxr, blank, helios, and lepaluddi! We still welcome community members to help out and get involved, so don’t be shy to reach out. The community also went truly global with multi-language channels in the Discord, so we will need multi-language help going forward.\n\n### Contributors helped meaningfully\n\nBeyond helping coordinate the community, there are tons of other ways to contribute, especially since all of Taiko became [fully open source](https://mirror.xyz/labs.taiko.eth/31vzkwgNaKNrze0oIv_wTKCw6Tha8OYQ6ffrquS3XUg) during the quarter. So whether you want to learn from, contribute, or fork any part of the codebase, please go ahead!\n\nTo make it as easy as possible to contribute, we wrote a [contribution guide](https://github.com/taikoxyz/taiko-mono/blob/main/CONTRIBUTING.md) covering coding standards, documentation standards/requests, and how you can earn a GitPOAP for your GitHub contributions to Taiko.\n\n### Team and extended-team expands\n\nFor those wanting to make contributing more of a full-time effort, we created a [careers page](/828fd7232d2c4150a11e10c8baa910a2) with several open positions we continue to hire for across engineering and operations.\n\nWe also launched the [Taiko Ambassador Program](https://mirror.xyz/labs.taiko.eth/BvcEyYeVIiHnjc-i5qf3zR4s67Jc6nz_R6OSGj5rzOE) to bring in talented developer advocates, community educators, and more. (Okay, technically this happened in Januray so not Q4 but wtvr.) We received over 1800 applications and are still going through them, so please hang tight! As mentioned, we only aim to onboard 2 to 4 Ambassadors in this first cohort, so if you don’t get onboard this time, please don’t be discouraged, there is always next cohort, and still plenty of ways to get involved and contribute outside that program.\n\n### Educated the community\n\nWe also wrote several educational blog posts covering topics such as [Type-1 ZK-EVMs](https://mirror.xyz/labs.taiko.eth/w7NSKDeKfJoEy0p89I9feixKfdK-20JgWF9HZzxfeBo) and [Rollup Decentralization](https://mirror.xyz/labs.taiko.eth/sxR3iKyD-GvTuyI9moCg4_ggDI4E4CqnvhdwRq5yL0A).\n\nOf course, the education didn’t stop with the blog, but took place across the [Taiko website](https://taiko.xyz/) which sports a new and improved look, and the same goes for our [documentation](https://taiko.xyz/docs/intro). Education also happened in-person, with a few presentations in Colombia and Portugal on the topics of [Layer-2 Finality](https://hackmd.io/@taikolabs/HkN7GR64i) and [Taiko Overview and Optimizations](https://hackmd.io/@taikolabs/S1haywHIj).\n\nWe had our first [community call](https://youtu.be/6wvd3gbcTTw) where several team members gave updates and answered questions to a packed house of over 2400 attendees! Looking forward to seeing you again at the next one.\n\n### Ecosystem development\n\nWith our first public testnet launched and quite overwhelming node, proposer, and user participation, our next focus is definitely growing our developer community! With that in mind, you will see Taiko’s presence at upcoming Ethereum ecosystem events, developer conferences, and hackathons. We look forward to meeting you all and helping scale Ethereum together.\n\n## Thank You\n\nAs you can tell, it was an exciting and important quarter for Taiko. As you can also tell, it was a team-wide and community-wide effort. None of this matters without empowering a broad community of developers, users, network participants and advocates — so a heartfelt thank you to all of you. We still have tons of work to do to scale Ethereum securely, let’s get it!\n\n### Join us\n\nExplore open positions on our [job board](https://www.notion.so/Taiko-Jobs-828fd7232d2c4150a11e10c8baa910a2).\n\n### Follow us\n\nTo stay updated on the latest from Taiko:\n\n* Website: [https://taiko.xyz](https://taiko.xyz/)\n\n* Discord: \n\n* GitHub: \n\n* Reddit: \n\n* Twitter: \n\n### Contribute\n\nContribute to Taiko and earn a GitPOAP! You will also be featured as a contributor on our README. Get started with the [contributing guide](https://github.com/taikoxyz/taiko-mono/blob/main/CONTRIBUTING.md).","timestamp":"1674500168","title":"Taiko Community Update — Q4/2022"},"digest":"jZDYA2FH7mgmCKSp_5xtLNCuO4fzoiC4LTdLpgHfUkU","authorship":{"contributor":"0x381636D0E4eD0fa6aCF07D8fd821909Fb63c0d10","signingKey":"{\"crv\":\"P-256\",\"ext\":true,\"key_ops\":[\"verify\"],\"kty\":\"EC\",\"x\":\"MH__-7G6Mn-OQkM_R8qyte-zM3nAbmt5Ji7rnqoQJzs\",\"y\":\"WTh6P8e0bgnDpFeNspkzcG0itWLKOhXNT8lUIND1lSE\"}","signature":"0xcd7827ffc43c64af46c1c28dd3dde2ac9cc8152a768c16db5db9639d9ea944f108a749eb840b8a72dddc9a701acfac627ad490230342a3b5b760eb9f3b540ea01c","signingKeySignature":"Dk25pgwk0aAIVSCdJ_mbmfMo3t0NWzYk_bBb38P1sp0r6qkulFLl7pXuF8PtUuZ2Y7l9n5ooKjS5cwxUEaGvIQ","signingKeyMessage":"I authorize publishing on mirror.xyz from this device using:\n{\"crv\":\"P-256\",\"ext\":true,\"key_ops\":[\"verify\"],\"kty\":\"EC\",\"x\":\"MH__-7G6Mn-OQkM_R8qyte-zM3nAbmt5Ji7rnqoQJzs\",\"y\":\"WTh6P8e0bgnDpFeNspkzcG0itWLKOhXNT8lUIND1lSE\"}","algorithm":{"name":"ECDSA","hash":"SHA-256"}},"version":"04-25-2022","wnft":{"chainId":10,"description":"Below is a brief summary of Taiko updates from Q4 2022. Now, 2023 is when ZK-EVMs are sure to leave an indelible mark on Ethereum and the world.","fee":250,"fundingRecipient":"0x5b796c4B197B6DfD413f177059C27963EB80af0F","imageURI":"QmeN9jeFWF4TnH6L9xCHPmvkodbWc83ex2yxvHzpvsfSmT","mediaAssetId":356760,"name":"Taiko Community Update — Q4/2022","nonce":5698305,"owner":"0x381636D0E4eD0fa6aCF07D8fd821909Fb63c0d10","price":0,"proxyAddress":"0xf1E81d367386cc01f4021b894B9e34DfAC953158","renderer":"0x0000000000000000000000000000000000000000","supply":500,"symbol":"TAIKOCOMMUNITYUPDATEQ42022"},"OriginalDigest":"OBggtj2uy03WvbPmuWV9X9nKsRQt8I-CbWlqpkqqdyI"},{"content":{"body":"*This post explores definitions and high-level ideas of rollup decentralization. It does not cover deep technical detail about decentralizing rollup implementations.*\n\nWe identify Taiko as a decentralized Ethereum-equivalent ZK-Rollup. Ethereum-equivalent - the moniker of a type-1 ZK-EVM - is a technical design decision that we describe [here](https://mirror.xyz/labs.taiko.eth/w7NSKDeKfJoEy0p89I9feixKfdK-20JgWF9HZzxfeBo).\n\nIn this post, we’d like to talk about the other descriptor in that statement: *decentralized*. We will explore:\n\n* What is the definition of a decentralized rollup?\n\n* How do you decentralize a rollup?\n\n* What are the tradeoffs of a decentralized rollup?\n\n* Taiko’s approach: progressive efficiency\n\n* Decentralized implementation & decentralized governance\n\n* How decentralization is part of Ethereum-equivalence\n\n## What is the definition of a decentralized rollup?\n\nYou may be surprised (or not) to learn that there is some disagreement on the definition of a decentralized rollup. We think we can get pretty close to a widely accepted definition, though:\n\n> A decentralized rollup is one where **any user can be sure that their transaction will be executed**.\n\nWe should take a moment to ask why one may even care whether a rollup is decentralized or not. Given that rollups rely on L1s for security guarantees (mainly Ethereum these days for the leading rollups), aren’t users covered no matter what?\n\nRollups guarantee that as long as the L1 (data availability layer) exists, users can reconstruct the L2 state and **exit the rollup by forcing a transaction on L1.** If the system doesn’t satisfy this constraint, then we would say it does not constitute a rollup; it is a different type of L2 or a sidechain. This should make it clear that choosing a strongly decentralized (always live, censorship-resistant) L1 is crucial. One further nuance is that for a general-purpose rollup, as opposed to an app-specific rollup, users must be able to **force the inclusion of any arbitrary transaction, not just ‘exit’ transactions**.\n\n![](https://images.mirror-media.xyz/publication-images/qgYzOIXPk9sAAJMkrXmz9.png?height=534&width=1522)\n\nOnce established that we are talking about a rollup, we put forth that the distinction that defines a rollup as decentralized or not lies with **how difficult or realistic it is for a user to be able to force their transaction to be included**. For instance, **do they need very powerful computing resources to generate a ZK proof?** Or can they use consumer hardware or rent a cheap server for a short amount of time? Is there some privileged actor that has free reign for an extended period, relegating one’s ability to try to be included to be delayed by 30 days? The less prohibitive, the more decentralized.\n\n![A spectrum exists between these extremes. \"Less decentralized\" is a thing.](https://images.mirror-media.xyz/publication-images/GRZmfwJCCO8SHRT8Q8v4t.png?height=518&width=1652)\n\nIn reality, a typical user would likely wish to avoid running a full rollup node, and in the case of a ZK-Rollup, the prover add-on. They would like to know that the rollup they transact on - or maybe even the rollup they call home - is conducive to having **a wide and diverse set of participants perform the necessary functions**. And that new participants can join the network to perform these functions, permissionlessly - including themselves, if they so wish.\n\nWith the above in mind, let’s finish this section with another definition of a decentralized rollup to help us gain a better understanding:\n\n> A decentralized rollup is one where **multiple parties can participate in each network position** - that is, as proposers, provers, and node runners.\n\nThis leads us to the next section.\n\n## How do you decentralize a rollup?\n\nGiven the above definitions, especially the second one, you may see that we can **decentralize a rollup by ensuring all roles can be performed by multiple parties** - ideally a vast and geographically-diverse set. Those roles are:\n\n* **Proposers**\n\n* **Provers**\n\n* **Node runners**\n\nBefore we review each role, let’s simply review a point touched on in the prior section: rollups, as an L2 solution, decide which L1 they are looking to scale, or more accurately, which L1 they will use for security guarantees. “Security guarantees” here means relying on L1 for consensus and data availability (DA). While this is not something that the rollup itself can tune towards decentralization, **choosing a sufficiently decentralized L1 is a critical decision**, and Taiko chooses Ethereum for the most robust security guarantees.\n\nOn to the roles.\n\n### Proposers\n\nProposers construct rollup blocks from users’ L2 transactions and propose them to L1. Sometimes these are referred to as *Sequencers* in other rollup systems.\n\nProposers decide **which transactions to include in a block and how to order them**. This is a powerful position as it can extract profit from transaction ordering and decide which transactions to exclude, and is thus able to censor certain transactions, applications, or users.\n\nAs we established —> a decentralized rollup should allow users to expect the **inclusion** of all of their valid transactions.\n\n### Provers\n\nProvers generate SNARK proofs asserting the validity of L2 transactions and blocks from the aforementioned proposed blocks.\n\nProvers decide **which proposed blocks to turn into *on-chain verified* blocks**. This position decides when a block can reach its on-chain verified state, but not which txs go in a block or how they are ordered. Until this on-chain verified state, the prover can leave hanging certain transactions that depend on the validity proof, or leave hanging certain *would-be* on-chain verified blocks that are waiting for their parent block to be on-chain verified.\n\nAs we established —> a decentralized rollup should allow users to expect **verification** of all of their valid transactions.\n\n### Node runners\n\nNode runners **execute transactions from on-chain (L1) data** to stay in sync with the rollup state.\n\nProposers and provers need to run full rollup nodes to fulfill their respective roles. Other actors would also want to run nodes, such as those offering services like a block explorer, infrastructure providers, and users who want to stay in sync with the chain state for other reasons.\n\nAs we established —> a decentralized rollup should allow users to expect **the execution** of all of their valid transactions.\n\n*Note: while decentralizing proposers/provers is an explicit rollup protocol decision (e.g. the smart contracts may be configured to only accept blocks or proofs from allowlisted addresses), running a node is mostly a resource consideration that depends on state growth, hardware requirements, etc., and is not an outright protocol decision. Catering to reasonable state growth is critical, but is not discussed in this post.*\n\n## What are the tradeoffs of a decentralized rollup?\n\nMoving along a spectrum of centralization to decentralization exposes a tradeoff space.\n\nFor this section, the pros and cons apply to both proposers and provers (which we collectively term *operators*); we will leave out node runners, as mentioned, but keep in mind that running a rollup node is a requirement for both roles.\n\nIn the context of rollup proposers/provers, we view the following:\n\n![](https://images.mirror-media.xyz/publication-images/H4fWx08a3pCgi9aoBplC1.jpg?height=1080&width=1470)\n\n## Taiko’s approach: progressive efficiency\n\nThe current approach chosen by most in-production general-purpose rollups has been one of centralization at first, with a commitment to progressive decentralization over time. This has made some sense, as there are several moving pieces, assumptions to test, and it is early. Having a centralized proposer and prover (aka sequencer and validator in broader terms) has made it more simple to ensure the proper and efficient functioning of the rollup. We can see this popular approach in the below table.\n\n![Source: L2beat.com. Displays different risks of rollups. For the topics we are discussing, a rollup with decentralized proposers and provers would have \"Propose Blocks\" in the Sequencer and Validator Failure columns (and it would be highly accessible for users to operate such). As you see, none of the above currently satisfies both. ](https://images.mirror-media.xyz/publication-images/SqkUnUfUBUPWV-eOCjHkG.png?height=808&width=2264)\n\nTaiko, on the other hand, aims to go live with a **fully decentralized (and permissionless) proposer and prover set**. The protocol will not enshrine or allowlist any parties; anyone will be able to perform those duties. Further, Taiko plans to have a minimal protocol-defined coordination scheme for proposers/provers. The current plan is for it to be leaderless.\n\nAll rollups will choose the sweet spot that suits the needs of their users. That spot will be different across rollups, and the *path* to reach the same spot may also be different. You can start centralized and loosen control, or you can start decentralized and implement tight coordination rules (or perhaps even assign control). It is certainly possible that some of the decentralization disadvantages are impediments to a suitably performing network, at which point Taiko can implement measures such as leader election schemes to avoid redundant work.\n\n> In this sense, Taiko’s approach may be considered **progressive efficiency**, as opposed to progressive decentralization; moving from the completely decentralized and unstructured extreme, and more towards the middle, if needed.\n\nThis is not to say that Taiko will be completely “[training-wheel-free](https://ethereum-magicians.org/t/proposed-milestones-for-rollups-taking-off-training-wheels/11571)” from the beginning. Certain measures like smart contract upgradeability will remain in place until things are battle-tested. This is guided by a security-minded approach: without proxy-based upgradability, users’ assets can face significant bug risks. Controlled upgradability is one of the levers that will be handed over to the DAO at some point.\n\n## Decentralized implementation and decentralized governance \n\nVitalik recently [wrote](https://vitalik.ca/general/2022/12/05/excited.html) that *“decentralized governance structure protects against attackers on the inside, and a decentralized implementation protects against powerful attackers on the outside.”* This was said in the context of DAOs - that is, both the governance structure *and* implementation pertained to DAOs. Specifically, it was said for one aim of DAO decentralization: robustness.\n\nWe think it is quite helpful to use this framing for rollups at large and split “governance structure” into meaning a rollup’s DAO, full stop (taking for granted the governance implementation is smart contract based), and “implementation” into meaning the rollup’s architecture itself.\n\n![Source: https://vitalik.ca/general/2022/12/05/excited.html](https://images.mirror-media.xyz/publication-images/e0I7SfTDP4eUIsrZ0hmtm.png?height=520&width=2580)\n\nIn this light, we have so far discussed how a rollup can defend itself against outside threats (censorship, liveness failures) with a decentralized implementation. **We mustn’t neglect how a rollup can defend itself against internal threats** - against the organization and community charged with initially building and maintaining it. The tool at a rollup’s disposal here is governance, or simplified, its DAO.\n\nWhen it comes to governance, Taiko adopts an approach that is similar to other rollups, and similar to most protocols on Ethereum in general, from DeFi to infrastructure. This approach is indeed one of progressive decentralization: control over the protocol will gradually be relinquished to the community, specifically to the Taiko DAO. It is too early to describe the details of the DAO and which governance mechanisms we would propose it adopts, but this will be the subject of future posts.\n\nAs a final thought on this topic: we view that **implementation offers a point-in-time analysis of a rollup’s properties, while governance can describe how the implementation may change over time**, and which parties can make those decisions.\n\n## How decentralization is part of Ethereum-equivalence\n\nOn its quest for pure Ethereum-equivalence, Taiko highly values its prioritization of decentralization. It would seem odd to have equivalence as a goal encompass the EVM, hash functions, state and tx trees, etc., without also connoting equivalence in network composition.\n\nEmulating Ethereum for Taiko means everything aligns towards Ethereum: the ZK-EVM, other Ethereum base layer architecture, philosophical considerations, community, and \\~vibes\\~. This extends to network decentralization and the main properties it provides for developers and their users: censorship-resistance and liveness.\n\nThanks for reading.\n\n### Join us\n\nExplore open positions on our [job board](https://www.notion.so/Taiko-Jobs-828fd7232d2c4150a11e10c8baa910a2).\n\n### Follow us\n\nTo stay updated on the latest from Taiko:\n\n* Website: [https://taiko.xyz](https://taiko.xyz/)\n\n* Discord: \n\n* GitHub: \n\n* Reddit: \n\n* Twitter: \n\n### Contribute\n\nContribute to Taiko and earn a GitPOAP! You will also be featured as a contributor on our README. Get started with the [contributing guide](https://github.com/taikoxyz/taiko-mono/blob/main/CONTRIBUTING.md).","timestamp":"1671562994","title":"Rollup Decentralization"},"digest":"uCDRVgVVRxRVbzKYgiY6_UgMPNV-uiPejcBasBemZ_8","authorship":{"contributor":"0x381636D0E4eD0fa6aCF07D8fd821909Fb63c0d10","signingKey":"{\"crv\":\"P-256\",\"ext\":true,\"key_ops\":[\"verify\"],\"kty\":\"EC\",\"x\":\"KLghZbUEjaY2lt26UoPwbZTQsrwW80OIsi64Hm-lLGc\",\"y\":\"ETAVyVNAc24z-k4CIt7wHxkxJKYuoOmsfuJrDnFZYsM\"}","signature":"0xd4bba22b4dbfb6403519d81ce7391c8aafcb801cb94bb4112f0c05fac2836b152a43c3cc7c457a2107fd5a118aad220d0ce620a6174bcae20dde6bd896a52db71b","signingKeySignature":"cqZ51jwr4Gpx3Q_hovb_OD6gWtqlK4gl86ZY3p6F1Hu_Tn0B__oF29BSL1OnyI_3TxbjHImVhRu1_Pgdt6Y4Yw","signingKeyMessage":"I authorize publishing on mirror.xyz from this device using:\n{\"crv\":\"P-256\",\"ext\":true,\"key_ops\":[\"verify\"],\"kty\":\"EC\",\"x\":\"KLghZbUEjaY2lt26UoPwbZTQsrwW80OIsi64Hm-lLGc\",\"y\":\"ETAVyVNAc24z-k4CIt7wHxkxJKYuoOmsfuJrDnFZYsM\"}","algorithm":{"name":"ECDSA","hash":"SHA-256"}},"version":"04-25-2022","wnft":{"chainId":10,"description":"Decentralized rollups ensure any user can have their transaction included, providing censorship-resistance and liveness guarantees.","fee":250,"fundingRecipient":"0x381636D0E4eD0fa6aCF07D8fd821909Fb63c0d10","imageURI":"QmTSTqMcWZUY4nMNA7FDYeZfBkC2MNWFZAH36729xZr1mP","mediaAssetId":321350,"name":"Rollup Decentralization","nonce":5609135,"owner":"0x381636D0E4eD0fa6aCF07D8fd821909Fb63c0d10","price":0,"proxyAddress":"0x8e4AF7682d1fa3C32CFA033Ae861e7c1533A83d0","renderer":"0x0000000000000000000000000000000000000000","supply":500,"symbol":"ROLLUPDECENTRALIZATION"},"OriginalDigest":"sxR3iKyD-GvTuyI9moCg4_ggDI4E4CqnvhdwRq5yL0A"}] \ No newline at end of file From 0a46e7cd8b88dcd8cb94d5d1bd72861d1e7139a7 Mon Sep 17 00:00:00 2001 From: Luuk Date: Wed, 22 Feb 2023 18:45:25 +0100 Subject: [PATCH 09/16] setup cron job --- .github/workflows/website.yml | 9 +++++++++ packages/website/components/BlogSection.tsx | 2 +- packages/website/package.json | 2 +- packages/website/{scripts => pages/api}/getPosts.js | 8 ++++---- 4 files changed, 15 insertions(+), 6 deletions(-) rename packages/website/{scripts => pages/api}/getPosts.js (94%) diff --git a/.github/workflows/website.yml b/.github/workflows/website.yml index ed0ed5ce488..9d5e543ab00 100644 --- a/.github/workflows/website.yml +++ b/.github/workflows/website.yml @@ -1,6 +1,8 @@ name: Website on: + schedule: + - cron: '0 1 * * *' push: branches: [main] paths: @@ -27,3 +29,10 @@ jobs: - name: Build Website run: pnpm -F website build + cron: + runs-on: ubuntu-latest + steps: + - name: Call our API route + run: | + curl --request POST \ + --url 'https://taiko.xyz/api/getPosts' diff --git a/packages/website/components/BlogSection.tsx b/packages/website/components/BlogSection.tsx index 98a7102e0bf..e70f0e9288c 100644 --- a/packages/website/components/BlogSection.tsx +++ b/packages/website/components/BlogSection.tsx @@ -84,7 +84,7 @@ export default function BlogSection(): JSX.Element { json = json.slice(0, 3); setPosts(json); }); - }); + },[]); return (
diff --git a/packages/website/package.json b/packages/website/package.json index 3a7643e600d..07aff283ca5 100644 --- a/packages/website/package.json +++ b/packages/website/package.json @@ -3,7 +3,7 @@ "version": "0.3.0", "private": true, "scripts": { - "build": "node scripts/getPosts.js && pnpm next build", + "build": "pnpm next build", "dev": "pnpm next dev", "start": "pnpm next start" }, diff --git a/packages/website/scripts/getPosts.js b/packages/website/pages/api/getPosts.js similarity index 94% rename from packages/website/scripts/getPosts.js rename to packages/website/pages/api/getPosts.js index 696eb0be54c..f8450ad2457 100644 --- a/packages/website/scripts/getPosts.js +++ b/packages/website/pages/api/getPosts.js @@ -7,7 +7,7 @@ const arweave = Arweave.init({ protocol: "https", }); -async function getTransanctionIds() { +export default async function getTransanctionIds(req, res) { await fetch("https://arweave.net/graphql", { method: "POST", headers: { @@ -48,6 +48,7 @@ async function getTransanctionIds() { .then((response) => { getPosts(response); }) + .finally(() => res.send(200)) .catch(); } @@ -66,7 +67,8 @@ async function getPosts(response) { data["OriginalDigest"] = edge.node.tags[4].value; posts.push(data); } - + }) + .then(() => { const jsonString = JSON.stringify(posts); fs.writeFile("./public/posts.json", jsonString, (err) => {}); }) @@ -74,5 +76,3 @@ async function getPosts(response) { }) ); } - -getTransanctionIds(); From e91c31d9ea931d3fd8e85c2b3a121d3295bfe0c5 Mon Sep 17 00:00:00 2001 From: Luuk Date: Thu, 23 Feb 2023 13:16:16 +0100 Subject: [PATCH 10/16] create workflow --- .github/workflows/fetch-blog.yml | 14 ++++++++++++++ .github/workflows/website.yml | 11 +---------- 2 files changed, 15 insertions(+), 10 deletions(-) create mode 100644 .github/workflows/fetch-blog.yml diff --git a/.github/workflows/fetch-blog.yml b/.github/workflows/fetch-blog.yml new file mode 100644 index 00000000000..39b925a7ab5 --- /dev/null +++ b/.github/workflows/fetch-blog.yml @@ -0,0 +1,14 @@ +name : Fetch Blog + +on: + schedule: + - cron: '12 1 * * *' + +jobs: + cron: + runs-on: ubuntu-latest + steps: + - name: Call our API route + run: | + curl --request POST \ + --url 'https://taiko.xyz/api/getPosts' \ No newline at end of file diff --git a/.github/workflows/website.yml b/.github/workflows/website.yml index 9d5e543ab00..fe5e4d6ae6e 100644 --- a/.github/workflows/website.yml +++ b/.github/workflows/website.yml @@ -1,8 +1,6 @@ name: Website on: - schedule: - - cron: '0 1 * * *' push: branches: [main] paths: @@ -28,11 +26,4 @@ jobs: uses: ./.github/actions/install-pnpm-dependencies - name: Build Website - run: pnpm -F website build - cron: - runs-on: ubuntu-latest - steps: - - name: Call our API route - run: | - curl --request POST \ - --url 'https://taiko.xyz/api/getPosts' + run: pnpm -F website build \ No newline at end of file From fdd75ffdbc6222046c530b16ab8865975a70055c Mon Sep 17 00:00:00 2001 From: Luuk Date: Thu, 23 Feb 2023 18:04:43 +0100 Subject: [PATCH 11/16] use node --- .github/workflows/fetch-blog.yml | 21 ++++++++++++++------ packages/website/{pages/api => }/getPosts.js | 10 +++++++--- 2 files changed, 22 insertions(+), 9 deletions(-) rename packages/website/{pages/api => }/getPosts.js (91%) diff --git a/.github/workflows/fetch-blog.yml b/.github/workflows/fetch-blog.yml index 39b925a7ab5..21ac09b20da 100644 --- a/.github/workflows/fetch-blog.yml +++ b/.github/workflows/fetch-blog.yml @@ -1,14 +1,23 @@ -name : Fetch Blog +name: Fetch Blog on: schedule: - - cron: '12 1 * * *' + - cron: "12 * * * *" jobs: cron: runs-on: ubuntu-latest steps: - - name: Call our API route - run: | - curl --request POST \ - --url 'https://taiko.xyz/api/getPosts' \ No newline at end of file + - name: Checkout repository + uses: actions/checkout@v3 + + - name: Install Node.js + uses: actions/setup-node@v3 + with: + node-version: 16 + + - name: Install pnpm dependencies + uses: ./.github/actions/install-pnpm-dependencies + + - name: Run getPosts + run: node packages/website/getPosts.js \ No newline at end of file diff --git a/packages/website/pages/api/getPosts.js b/packages/website/getPosts.js similarity index 91% rename from packages/website/pages/api/getPosts.js rename to packages/website/getPosts.js index f8450ad2457..a16166eb222 100644 --- a/packages/website/pages/api/getPosts.js +++ b/packages/website/getPosts.js @@ -7,7 +7,7 @@ const arweave = Arweave.init({ protocol: "https", }); -export default async function getTransanctionIds(req, res) { +async function getTransanctionIds() { await fetch("https://arweave.net/graphql", { method: "POST", headers: { @@ -48,7 +48,6 @@ export default async function getTransanctionIds(req, res) { .then((response) => { getPosts(response); }) - .finally(() => res.send(200)) .catch(); } @@ -70,9 +69,14 @@ async function getPosts(response) { }) .then(() => { const jsonString = JSON.stringify(posts); - fs.writeFile("./public/posts.json", jsonString, (err) => {}); + fs.writeFile( + "packages/website/public/posts.json", + jsonString, + (err) => {} + ); }) .catch(); }) ); } +getTransanctionIds(); From 6d7a6e98bdfe7b18568c4f37ac48e3edc3f5a0a2 Mon Sep 17 00:00:00 2001 From: Luuk Date: Fri, 24 Feb 2023 15:08:29 +0100 Subject: [PATCH 12/16] Revert "use node" This reverts commit fdd75ffdbc6222046c530b16ab8865975a70055c. --- .github/workflows/fetch-blog.yml | 21 ++++++-------------- packages/website/{ => pages/api}/getPosts.js | 10 +++------- 2 files changed, 9 insertions(+), 22 deletions(-) rename packages/website/{ => pages/api}/getPosts.js (91%) diff --git a/.github/workflows/fetch-blog.yml b/.github/workflows/fetch-blog.yml index 21ac09b20da..39b925a7ab5 100644 --- a/.github/workflows/fetch-blog.yml +++ b/.github/workflows/fetch-blog.yml @@ -1,23 +1,14 @@ -name: Fetch Blog +name : Fetch Blog on: schedule: - - cron: "12 * * * *" + - cron: '12 1 * * *' jobs: cron: runs-on: ubuntu-latest steps: - - name: Checkout repository - uses: actions/checkout@v3 - - - name: Install Node.js - uses: actions/setup-node@v3 - with: - node-version: 16 - - - name: Install pnpm dependencies - uses: ./.github/actions/install-pnpm-dependencies - - - name: Run getPosts - run: node packages/website/getPosts.js \ No newline at end of file + - name: Call our API route + run: | + curl --request POST \ + --url 'https://taiko.xyz/api/getPosts' \ No newline at end of file diff --git a/packages/website/getPosts.js b/packages/website/pages/api/getPosts.js similarity index 91% rename from packages/website/getPosts.js rename to packages/website/pages/api/getPosts.js index a16166eb222..f8450ad2457 100644 --- a/packages/website/getPosts.js +++ b/packages/website/pages/api/getPosts.js @@ -7,7 +7,7 @@ const arweave = Arweave.init({ protocol: "https", }); -async function getTransanctionIds() { +export default async function getTransanctionIds(req, res) { await fetch("https://arweave.net/graphql", { method: "POST", headers: { @@ -48,6 +48,7 @@ async function getTransanctionIds() { .then((response) => { getPosts(response); }) + .finally(() => res.send(200)) .catch(); } @@ -69,14 +70,9 @@ async function getPosts(response) { }) .then(() => { const jsonString = JSON.stringify(posts); - fs.writeFile( - "packages/website/public/posts.json", - jsonString, - (err) => {} - ); + fs.writeFile("./public/posts.json", jsonString, (err) => {}); }) .catch(); }) ); } -getTransanctionIds(); From 97cfca1d3563c51bbd37c0737a06c46842d01d5b Mon Sep 17 00:00:00 2001 From: Luuk Date: Fri, 24 Feb 2023 20:29:34 +0100 Subject: [PATCH 13/16] fix curl --- .github/workflows/fetch-blog.yml | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/.github/workflows/fetch-blog.yml b/.github/workflows/fetch-blog.yml index 39b925a7ab5..35084f750dd 100644 --- a/.github/workflows/fetch-blog.yml +++ b/.github/workflows/fetch-blog.yml @@ -10,5 +10,4 @@ jobs: steps: - name: Call our API route run: | - curl --request POST \ - --url 'https://taiko.xyz/api/getPosts' \ No newline at end of file + curl --request POST --url 'https://taiko.xyz/api/getPosts' \ No newline at end of file From a0af966d0926ba76d8d771d42d222f356f580a20 Mon Sep 17 00:00:00 2001 From: Luuk Date: Sun, 26 Feb 2023 17:16:07 +0100 Subject: [PATCH 14/16] setup api, remove cron --- .github/workflows/fetch-blog.yml | 13 ------------ packages/website/components/BlogSection.tsx | 2 +- packages/website/pages/api/getPosts.js | 22 ++++++++++++--------- packages/website/public/posts.json | 1 - 4 files changed, 14 insertions(+), 24 deletions(-) delete mode 100644 .github/workflows/fetch-blog.yml delete mode 100644 packages/website/public/posts.json diff --git a/.github/workflows/fetch-blog.yml b/.github/workflows/fetch-blog.yml deleted file mode 100644 index 35084f750dd..00000000000 --- a/.github/workflows/fetch-blog.yml +++ /dev/null @@ -1,13 +0,0 @@ -name : Fetch Blog - -on: - schedule: - - cron: '12 1 * * *' - -jobs: - cron: - runs-on: ubuntu-latest - steps: - - name: Call our API route - run: | - curl --request POST --url 'https://taiko.xyz/api/getPosts' \ No newline at end of file diff --git a/packages/website/components/BlogSection.tsx b/packages/website/components/BlogSection.tsx index e70f0e9288c..0846c9099b8 100644 --- a/packages/website/components/BlogSection.tsx +++ b/packages/website/components/BlogSection.tsx @@ -77,7 +77,7 @@ function getDateTime(timestamp: string): string { export default function BlogSection(): JSX.Element { const [posts, setPosts] = useState([]); useEffect(() => { - fetch("/posts.json") + fetch("/api/getPosts") .then((response) => response.json()) .then((json) => { json = json.sort((a, b) => b.content.timestamp - a.content.timestamp); diff --git a/packages/website/pages/api/getPosts.js b/packages/website/pages/api/getPosts.js index f8450ad2457..08af56cfd14 100644 --- a/packages/website/pages/api/getPosts.js +++ b/packages/website/pages/api/getPosts.js @@ -1,5 +1,4 @@ const Arweave = require("arweave"); -const fs = require("fs"); const arweave = Arweave.init({ host: "arweave.net", @@ -7,7 +6,10 @@ const arweave = Arweave.init({ protocol: "https", }); -export default async function getTransanctionIds(req, res) { +const posts = []; +const hoursBetweenBlogPostFetches = 1 + +const getTransactionIds = async () => { await fetch("https://arweave.net/graphql", { method: "POST", headers: { @@ -48,12 +50,11 @@ export default async function getTransanctionIds(req, res) { .then((response) => { getPosts(response); }) - .finally(() => res.send(200)) .catch(); -} +}; async function getPosts(response) { - const posts = []; + posts.length = 0; Promise.all( response.data.transactions.edges.map((edge) => { const transactionId = edge.node.id; @@ -68,11 +69,14 @@ async function getPosts(response) { posts.push(data); } }) - .then(() => { - const jsonString = JSON.stringify(posts); - fs.writeFile("./public/posts.json", jsonString, (err) => {}); - }) .catch(); }) ); } + +getTransactionIds(); +setInterval(getTransactionIds, hoursBetweenBlogPostFetches * 3600000); + +export default (req, res) => { + res.json(posts); +}; diff --git a/packages/website/public/posts.json b/packages/website/public/posts.json deleted file mode 100644 index f1fdbd30e7f..00000000000 --- a/packages/website/public/posts.json +++ /dev/null @@ -1 +0,0 @@ -[{"content":{"body":"Taiko Community Update #3 has arrived 🥁\n\nWe do these to provide transparency into the progress we’ve made since our [last community update](https://mirror.xyz/labs.taiko.eth/JdMMaBLOtK3Hk_SGZy_c9WFEnn1jDtOpfeXVHxJAtMU). These updates represent our most recent two-week work iteration.\n\n# Team wide ✨\n\n* Added the MIT License to [taiko-mono](https://github.com/taikoxyz/taiko-mono).\n\n* Posted a blog entry: [Taiko is fully open source](https://mirror.xyz/labs.taiko.eth/31vzkwgNaKNrze0oIv_wTKCw6Tha8OYQ6ffrquS3XUg).\n\n* Updated the Taiko website at [taiko.xyz](https://taiko.xyz/).\n\n* Added [protocol contract documentation](https://taiko.xyz/docs/category/smart-contracts) to the website.\n\n* Added language channels to the Discord. [Join us](https://discord.com/invite/taikoxyz)!\n\n* Minted [2022 Taiko Contributor (Founding Year) GitPOAPs](https://www.gitpoap.io/gp/686).\n\n# ZK-EVM 🔬\n\n* Added tests for math gadgets.\n\n* Adding support for skipping over invalid transactions in the circuits.\n\n* Reviewing and refactoring the Merkle Patricia Tree circuit.\n\n* Investigating alternative proving systems.\n\n# Protocol 🧑‍🔬\n\n* Simplified the protocol contract documentation.\n\n* Various small improvements and optimizations.\n\n# Node 🌐\n\n* Enable p2p blocks fast synchronization among L2 nodes.\n\n* Added the ability to enable prover allowlisting for the testnet.\n\n# Bridge 🌉\n\n* Worked on the bridge deployment.\n\n* Connecting the bridge UI with the relayer.\n\n* Improved bridge UI, including mobile responsiveness.\n\n\n---\n\n## Join us\n\nExplore open positions on our [job board](https://www.notion.so/taikoxyz/Taiko-Jobs-828fd7232d2c4150a11e10c8baa910a2).\n\n## Follow us\n\nJoin the community on Discord and follow us on Twitter!\n\nTo stay updated on the latest from Taiko:\n\n* Website: [https://taiko.xyz](https://taiko.xyz/)\n\n* Discord: \n\n* GitHub: \n\n* Reddit: [https://www.reddit.com/r/taiko_xyz](https://www.reddit.com/r/taiko_xyz/)\n\n* Twitter: \n\n## Contribute\n\nContribute to Taiko and earn a GitPOAP! You will also be featured as a contributor on our README. Get started with the [contributing guide](https://github.com/taikoxyz/taiko-mono/blob/main/CONTRIBUTING.md).\n\n## Thank you 🙏\n\nBig thanks to all our community members and contributors. ❤️\n\nWe might miss a few of you, but specific shoutouts to:\n\n* **omahs** for fixing a typo in the documentation\n\n* **1xDeFi** for adding the meaning of \"Taiko\" to [Frequently asked questions](https://taiko.xyz/faq#what-does-taiko-mean)\n\n* **Etherdad.lens** for the educational Twitter [thread](https://twitter.com/etherdad10/status/1600159537578721280)\n\n* **wolfderechter** for tidying up the footer links on [taiko.xyz](https://taiko.xyz/)\n\n* **Vitalik Buterin** for the recognition & [shout out on Twitter](https://twitter.com/taikoxyz/status/1600236704253689856)","timestamp":"1670537576","title":"Taiko Community Update #3"},"digest":"R_NMPTPUKrXhRYQS_v6Y6rpw_QvnjZmTvPYLS9YL23M","authorship":{"contributor":"0x2b1F13149C7F89622BBfB46Ae1e3ECc573Bb9331","signingKey":"{\"crv\":\"P-256\",\"ext\":true,\"key_ops\":[\"verify\"],\"kty\":\"EC\",\"x\":\"pn7a0q111AR7PdQJY_VEXF1ZsMx4wyPJvbErRkirSb8\",\"y\":\"k53QCfxPK3N6NoEF2_9P3EUfo6w3MLsUSJmISPVnXFk\"}","signature":"0x8a3a0425b477f54c0f8e963212b6238a7213b770fdae58b5a8f7f5e22baf77cd1fdcf43fb2ce72664fa98700370508237dd987bb4c995857b2505d0757ae8c8f1b","signingKeySignature":"Z4ehuQisTC2rw_UpbtmvBZbfDI5Gf0KiVu65xx1nkC3AsIANPxH0EwCe67_KIAIYTxnHwnTe1tkUwGcMxx2oIA","signingKeyMessage":"I authorize publishing on mirror.xyz from this device using:\n{\"crv\":\"P-256\",\"ext\":true,\"key_ops\":[\"verify\"],\"kty\":\"EC\",\"x\":\"pn7a0q111AR7PdQJY_VEXF1ZsMx4wyPJvbErRkirSb8\",\"y\":\"k53QCfxPK3N6NoEF2_9P3EUfo6w3MLsUSJmISPVnXFk\"}","algorithm":{"name":"ECDSA","hash":"SHA-256"}},"version":"04-25-2022","wnft":{"chainId":10,"description":"Taiko Community Update #3 has arrived 🥁\n","fee":250,"fundingRecipient":"0x5b796c4B197B6DfD413f177059C27963EB80af0F","imageURI":"QmQUVJvSeTrAqEzwjRg4c5MrMdWrvMEZqo1J6C3AjXJv7B","mediaAssetId":308118,"name":"Taiko Community Update #3","nonce":2705515,"owner":"0x2b1F13149C7F89622BBfB46Ae1e3ECc573Bb9331","price":0,"proxyAddress":"0xE73283Ebc2fC980aa83DF9De557077Ce21d54310","renderer":"0x0000000000000000000000000000000000000000","supply":500,"symbol":"TAIKOCOMMUNITYUPDATE3"},"OriginalDigest":"8E_7fjFNFjY7dIGAppqaNyuM-1QXp78AekXMA9--q6o"},{"content":{"body":"Dear Taiko community,\n\nWe would like to share an update with you about Taiko’s progress. Please [reach out](http://info@taiko.xyz/) if you have questions or suggestions.\n\n# Team\n\nIn July, Brecht Devos joined Taiko as our third co-founder. Brecht used to work for Loopring as the Chief Architect, but over the last 12 months or so, he had been working on [PSE](https://github.com/privacy-scaling-explorations)’s [zkEVM](https://github.com/privacy-scaling-explorations/zkevm-circuits) with researchers and engineers from the Ethereum Foundation and other open-source projects. Brecht leads Taiko’s Zero-Knowledge R&D team with an objective to implement all remaining EVM opcodes and to customize the zkEVM to fit Taiko’s layer 2 protocol design.\n\nWe have hired four cryptographers from Turkey, Austria, Barbados, and Ukraine. The first three have already been onboarded and Aleksei will join on November 1st.\n\nThere is also a new backend engineer joined in Shanghai and two protocol & frontend engineer from India and Canada. Two more engineers are joining us from the US to work on bridges.\n\nWe have also started to activate our Discord and Twitter communities, thanks to the involvement of our new community managers. They have already brought onboard several dedicated moderators to help attract, engage and retain a broader community.\n\nThe Taiko team is now a twenty persons team across twelve countries covering all continents with most people having an engineering/research background.\n\n![](https://images.mirror-media.xyz/publication-images/i65bAIoAy9kCFehfrbYlu.png?height=1800&width=3200)\n\n# Development\n\n### ZK-EVM\n\nMost opcodes are fully implemented in the EVM circuit, with a small number still remaining to be done. Work has started on adding support for so-called precompiled contracts which can be called from smart contracts and need special handling.\n\nA lot of progress has been made on the aggregation circuit, which is the circuit that allows the verification of proofs inside another proof. This is an important circuit for connecting the different ZK-EVM circuits together in a way that can be verified efficiently on Ethereum.\n\nBecause the goal is to build a type-1 (fully Ethereum-equivalent) ZK-EVM, we need to make sure there are no technical limitations that prevent us from building such a system. PLONKish circuits don't have any real limitations on what can be proven, but certain problems don't map very well to circuits, which results in high proving times. The hash functions used in Ethereum are a good example of this specifically for a type-1 ZK-EVM. Prover times can be improved by optimizations on the circuit level, optimizations on the prover level, and optimizations on the prover system level. Many such optimizations for the different ZK-EVM circuits have been done on the circuit level (e.g. keccak256/sha256) and on the prover level. We will be continuing these efforts, while the newly joined cryptography researchers will be able to help us to do optimizations on the prover system level as well.\n\n### Protocol\n\nWe deprecated Taiko protocol V1 (). V1 was built on top of Proof-of-Stake as we require that block proposers must prove their own blocks (which is no longer the case).\n\nThe new protocol (V2) has a different set of design objectives and assumptions on what a ZK-EVM can and cannot prove. As a [type-1 zkRollup](https://vitalik.ca/general/2022/08/04/zkevm.html), Taiko protocol V2 is more secure, minimal, robust, decentralized, permissionless, Ethereum-Aligned, and Ethereum-Equivalent. We have also mitigated MEV challenges with a commit-then-propose scheme. But the most powerful feature for users is the immediate block finality - people only need to wait for a L1 confirmation to have their Taiko L2 transactions finalized.\n\nThe new protocol has been implemented, reviewed, and is being used by the Taiko node software. However, it demands comprehensive unit and integration testing.\n\nOur [draft whitepaper](https://github.com/taikochain/whitepaper/releases/download/v1.0.0/taiko-whitepaper.pdf) is ready for you to review.\n\n![](https://images.mirror-media.xyz/publication-images/MWdBeHKvCtQyT7QG8EvsT.png?height=2116&width=3108)\n\n### Bridge\n\nWe have also re-implemented our default cross-chain bridge. The new bridge only assumes the two chains are both EVM-based and that some block headers are synchronized between the two chains on a regular basis. Bridge design is not covered by our whitepaper but the bridge source code is [open-sourced](https://github.com/taikochain/taiko-mono) together with our rollup protocol.\n\n### Node & Testnet\n\nOur new [node implementation](https://github.com/taikochain/client-mono) for protocol V2 takes a difference approach from V1: the new architectures is built on top of Ethereum’s engine API design and split into multiple binaries.\n\nWith this new design, we are able to maintain the a maximal level of compatibility with the go-ethereum codebase.\n\nThe private alpha-1 testnet with only a few nodes has been up and running without actual ZKPs. Nodes in alpha-1 are interacting with each other in simple ways. We are working to simulate more complex scenarios to further test inter-node and cross-layer interactions. A private blockchain explorer is up and running for internal development and testing purpose only.\n\n![](https://images.mirror-media.xyz/publication-images/1Ct0O7u5wcUKIzLWel2Bh.png?height=2164&width=2698)\n\nIt’s too early to request testnet access, your patience will be appreciated.\n\n## Future Updates\n\nMoving forward, Taiko Labs will share updates with our communities at the end of each quarter. We thank you for being part of our exciting journey.\n\n\n\n","timestamp":"1666529746","title":"Taiko Community Update - Q3 2022"},"digest":"A4bKjhlGqAFM9E3YvLHoAp29O4fW1lpVzlzMzThX1SY","authorship":{"contributor":"0x5b796c4B197B6DfD413f177059C27963EB80af0F","signingKey":"{\"crv\":\"P-256\",\"ext\":true,\"key_ops\":[\"verify\"],\"kty\":\"EC\",\"x\":\"Idj9037DpsOvwoPpOcL60W62ZKkqLnMgxzSZKU_R61I\",\"y\":\"rm2Tp_RyIHaQcKSfub2FY6Dhvw-wpXmqIpFFM_a6Ohg\"}","signature":"0xe61e02914b37b4dc18b1d57acfc5573cc18f129f632953fc485dfd2a45a3bf4e2c1945e1ca3dc85dcb6b4a348d0b7b1c62d08e52c3ca78bf36977187363c35a51c","signingKeySignature":"wBcUQHe309FCDSvTRlG60dbjyiagSgIfEteSy9_jUF3LyznQP-A07VIKTWVuHmxwiQzAHKnzbr-6N5mkUJr-yA","signingKeyMessage":"I authorize publishing on mirror.xyz from this device using:\n{\"crv\":\"P-256\",\"ext\":true,\"key_ops\":[\"verify\"],\"kty\":\"EC\",\"x\":\"Idj9037DpsOvwoPpOcL60W62ZKkqLnMgxzSZKU_R61I\",\"y\":\"rm2Tp_RyIHaQcKSfub2FY6Dhvw-wpXmqIpFFM_a6Ohg\"}","algorithm":{"name":"ECDSA","hash":"SHA-256"}},"version":"04-25-2022","wnft":{"chainId":10,"description":"Dear Taiko community,\n","fee":250,"fundingRecipient":"0x5b796c4B197B6DfD413f177059C27963EB80af0F","imageURI":"bafybeiajw4ckkw35iiw6blzoqmntrb5rfs6d6uwpirv7tgbhh2244kxqfq","mediaAssetId":250598,"name":"Taiko Community Update - Q3 2022","nonce":7755661,"owner":"0x5b796c4B197B6DfD413f177059C27963EB80af0F","price":0,"proxyAddress":"0xed8112AEB72684ce0Bb1fbB0e8B06FAd753b9299","renderer":"0x0000000000000000000000000000000000000000","supply":500,"symbol":"TAIKOCOMMUNITYUPDATE-Q32022"},"OriginalDigest":"dCl9V1KkqF99xlDbho6fAOm5zoqU4Irk7PymLMwTiCc"},{"content":{"body":"Hey everyone 👋, we want to update you on the progress we’ve made since our [last community update](https://mirror.xyz/labs.taiko.eth/dCl9V1KkqF99xlDbho6fAOm5zoqU4Irk7PymLMwTiCc).\n\n## R&D\n\n### Node & Client\n\n* Deployed a Grafana dashboard to monitor our own testnet nodes / services.\n\n* Deployed HIVE for the L2 nodes / services integration tests.\n\n### Protocol\n\n* Published the initial tokenomics proposal (in review), which can be viewed at the [latest whitepaper](https://taikoxyz.github.io/taiko-mono/taiko-whitepaper.pdf).\n\n* Reduced commitBlock gas cost (in review).\n\n### Bridge\n\n* Made progress on the bridge relayer and bridge UI.\n\n* Moved stack from React to Svelte + Tailwind + daisyUI.\n\n* Improved bridge documentation.\n\n### ZK-EVM\n\n* Miscellaneous contributions to the community [ZK-EVM project](https://github.com/privacy-scaling-explorations/zkevm-circuits) such as a `RETURENDATACOPY` opcode implementation and circuit benchmarks.\n\n* Ongoing investigation into newer proving systems (HyperPlonk, FRI based solutions) and circuit optimizations (non-native field arithmetic).\n\n### All\n\n* Open sourced [taiko-mono](https://github.com/taikoxyz/taiko-mono) with [contributing guide](https://github.com/taikoxyz/taiko-mono/blob/main/CONTRIBUTING.md).\n\n* Added code coverage calculations and badges for our projects.\n\n* Fleshed out requirements and design for the testnet launch.\n\n* Published the [Taiko jobs page](https://www.notion.so/Taiko-Jobs-828fd7232d2c4150a11e10c8baa910a2).\n\n* Updated all link handles to point to `taikoxyz` instead of `taikochain`.\n\n## Community\n\n### Events\n\nTalked about [Layer 2 Finality](https://hackmd.io/@taikolabs/HkN7GR64i) at the [IOSG conference](https://twitter.com/IOSGVC/status/1587432916753481729?s=20&t=GewTXWDoqCW3z9iqf83Nig) in Lisbon.\n\n### Discord\n\nAdded a new moderator, welcome `ex_sxcr`!\n\n### Website\n\n* Updated [taiko.xyz](http://taiko.xyz) with some good ‘getting started’ materials and a Talks section.\n\n* Moved all presentations from Google slides to HackMD, and added them to Talks.\n\n### Publications\n\n* Published an internal presentation from Daniel to new engineers at Taiko, explaining the Taiko protocol — this can be viewed on our new [YouTube channel](https://www.youtube.com/@taikoxyz).\n\n* Published a blog post on [The Type 1 ZK-EVM](https://mirror.xyz/labs.taiko.eth/w7NSKDeKfJoEy0p89I9feixKfdK-20JgWF9HZzxfeBo).\n\n### Contributors\n\n* Progress on GitPOAP for contributors has been made, you can look forward to that soon!\n\n* Added contributors section to the [taiko-mono README](https://github.com/taikoxyz/taiko-mono/blob/main/README.md).\n\n* Added [issue templates](https://github.com/taikoxyz/taiko-mono/issues/new/choose) so you can now easily report bugs and request features (will be recognized on our README and eligible for a GitPOAP).\n\n## Thank you\n\nAs a decentralized and open source project, we’d like to thank those who have helped out in our community to improve Taiko.\n\n* `HV` for creating a blog post: [What is Taiko? For Beginners](https://mirror.xyz/0x465918b217D2eF4a70ee8983C2C92D2Cfc4347eF/QVf_0otb_MYt9aAkaICjuG9WjjxXh7WVXkDUUjLC-Wg)\n\n* `ex_sxcr` for joining as a moderator and helping answer questions + provide clarity.\n\n* `qukuaizhao` for the good vibes in Discord ❤️.\n\n* Everyone else on the Discord helping to answer questions and promote learning about Ethereum and Taiko.\n\n \n\n","timestamp":"1669351810","title":"Taiko Community Update #2"},"digest":"yZSSixijWKLYos1OaY_IjlanIJ2lVhLPJqDB7t-GIQ8","authorship":{"contributor":"0x5b796c4B197B6DfD413f177059C27963EB80af0F","signingKey":"{\"crv\":\"P-256\",\"ext\":true,\"key_ops\":[\"verify\"],\"kty\":\"EC\",\"x\":\"yO8_glhQHXQ98Uozu7VdJBtRtgmUCiCmypAv3YT8Je4\",\"y\":\"H5lKGo1wDGrJIpdIlfQyQVUE0QfkVnntGl6x-d6KUek\"}","signature":"0xbb7188c782e10bdc38ae92cc78e65eae8a0b21a161ab2331cc4ee77ccf46ea30500b6c6bb2e5c1475d31c2c4b2776c29f8ef4da83c0c40223df2a5e71e8ce9921c","signingKeySignature":"bWmCj-JUuYcZWIMZba7Y9bfVy3N_35NIU__SHZ3Ez6khhqI-GsBmm7x7oTvB-38DxIsz3PFcMUm8ypBqyBWwOg","signingKeyMessage":"I authorize publishing on mirror.xyz from this device using:\n{\"crv\":\"P-256\",\"ext\":true,\"key_ops\":[\"verify\"],\"kty\":\"EC\",\"x\":\"yO8_glhQHXQ98Uozu7VdJBtRtgmUCiCmypAv3YT8Je4\",\"y\":\"H5lKGo1wDGrJIpdIlfQyQVUE0QfkVnntGl6x-d6KUek\"}","algorithm":{"name":"ECDSA","hash":"SHA-256"}},"version":"04-25-2022","wnft":{"chainId":10,"description":"Hey everyone 👋, we want to update you on the progress we’ve made since our last community update.\n","fee":250,"fundingRecipient":"0x5b796c4B197B6DfD413f177059C27963EB80af0F","imageURI":"QmRoweCRkwgZMLCwwvxeDNmiSQn21PCySKbXT7MYX86Nyk","mediaAssetId":290565,"name":"Taiko Community Update #2","nonce":5068761,"owner":"0x5b796c4B197B6DfD413f177059C27963EB80af0F","price":0,"proxyAddress":"0x7f43A377a1EA156956d5f41dD5aA549712167063","renderer":"0x0000000000000000000000000000000000000000","supply":500,"symbol":"TAIKOCOMMUNITYUPDATE2"},"OriginalDigest":"JdMMaBLOtK3Hk_SGZy_c9WFEnn1jDtOpfeXVHxJAtMU"},{"content":{"body":"**Taiko scales Ethereum in a manner that emulates Ethereum as closely as possible - both technically and non-technically. More specifically, Taiko is an Ethereum-equivalent ZK-Rollup, scaling Ethereum by supporting all EVM opcodes in a layer-2 architecture that is decentralized, permissionless, and secure.**\n\nEthereum represents an enormous leap forward in the mechanisms available for human coordination and personal freedom.\n\nAs a global, credibly neutral settlement layer, Ethereum provides strong digital ownership rights, and offers anyone the ability to move value where and when they want. It is the protocol underpinning an internet of value, and not since the internet itself have we witnessed a network where movement is so fluid.\n\nMore than movement, creation of value is equally fluid and unbounded. The creative power of developers deploying their smart contracts and applications to an always-on, always-accessible, borderless computer is remarkable.\n\nTo achieve the above, Ethereum has had to (rightfully) prioritize certain blockchain attributes over others - namely, decentralization and security over scalability. If a public blockchain is not decentralized and secure, then it is not credibly neutral, and thus not attractive to house highly-valuable, highly-critical functions. However, if a public blockchain is not scalable, then large portions of developers, users, and use cases cannot leverage the network, due to prohibitively high transaction fees and low throughput.\n\nTo *fully* achieve the impact of which it is capable, Ethereum must necessarily support anyone who wants to participate. Ethereum must be scalable to the human population. This is where Ethereum looks towards [rollups](https://vitalik.ca/general/2021/01/05/rollup.html) as the most promising scaling solution, and the most promising type of rollup is an Ethereum-equivalent ZK-Rollup.\n\nTaiko aims to be a fully Ethereum-equivalent ZK-Rollup. We aim to scale Ethereum in a manner that emulates Ethereum itself at a technical level, and a principles level.\n\n## Taiko Technical Overview\n\nZK-Rollups scale computation by executing, aggregating, and proving transactions off-chain, and relying on Ethereum for data availability and validity proof verification. The biggest drawback of the currently in-production ZK-Rollups are that they cannot support the generalized computation of the EVM exactly, but instead are mostly application-specific. This breaks compatibility with existing Ethereum L1 smart contracts and dapps, and further, makes it difficult to build new ones that offer the same type of composable, expressive experiences.\n\nEthereum-equivalent ZK-Rollups, sometimes called ZK-EVMs, are the holy grail of layer-2 scaling solutions in that they do not compromise on security or compatibility. In recent parlance, Taiko aims to be a [type-1 ZK-EVM](https://vitalik.ca/general/2022/08/04/zkevm.html), which prioritizes perfect EVM/Ethereum-equivalence over ZK-proof generation speed.\n\nTaiko consists of three main parts: the ZK-EVM circuits (for proof generation), the L2 rollup node (for managing the rollup chain), and the protocol on L1 (for connecting these two parts together for rollup protocol verification).\n\n### 1\\. ZK-EVM\n\nThe ZK-EVM proves the correctness of the EVM computations on the rollup with validity proofs.\n\nTaiko can run Ethereum smart contract code as is, zero changes necessary. Developers can migrate their existing Ethereum smart contracts and full dapps to Taiko trivially, or of course implement their new solidity code on Taiko as their first/only environment. Taiko implements a ZK-EVM that supports every EVM opcode, producing a validity proof of the[ ZK-EVM circuit](https://github.com/privacy-scaling-explorations/zkevm-circuits). Besides perfect compatibility with Ethereum L1 smart contracts and dapps, this also means that all Ethereum and solidity tooling works seamlessly with Taiko, no need to disrupt developers’ workflow whatsoever.\n\nThe result of this is two-fold:\n\n1. Developer experience is exactly what solidity smart contract developers are already used to - no wasted time, no friction. The momentum behind EVM developers and Ethereum smart contracts are unstoppable, and that momentum need not be diverted or slowed.\n\n2. Smart contracts (and systems of smart contracts/dapps) that have been running on Ethereum - in many cases for years, with billions of dollars of value therein - are battle-hardened, and could port over to Taiko without introducing risk of compiling them to a different language, or otherwise tweaking the framework. That means porting over the exact dapps, or the smart contract building blocks/patterns of development.\n\nBeyond the benefits of EVM-equivalence, which mostly manifests itself at the application layer, Taiko aims for Ethereum-equivalence, allowing it to make use of existing Ethereum infrastructure, such as execution clients, easily repurposed as Taiko nodes. For instance, the Taiko client is currently based on the battle-hardened Go-Ethereum client. So, not only is the VM perfectly compatible, but the ‘surrounding tissue’ is as well, given Taiko nodes use the same hashing algorithm, signature scheme, and storage data structure as Ethereum. Importantly, Taiko seeks to be Ethereum-equivalent going forward as well; if there are Ethereum protocol updates, Taiko will implement them in our zkEVM to maintain synchronization. Finally, if Taiko creates compelling new directions from our own R&D, we can work to have them implemented on Ethereum, helping the L1.\n\nIn terms of compatibility, it is not just developers and infrastructure providers that will have a smooth time on the Taiko rollup, but users as well. On Taiko, the user experience, usage patterns, and products will all be completely familiar to users.\n\nIt is worth pausing to reflect on a meta-thought about why the above is so important. As a general purpose L2, Taiko’s goal is to empower builders, who ultimately empower users. **We build what we build so others can do what they do.**\n\n**Taiko will only make a difference in this world if it helps others make a difference in this world.** Harnessing the power of Ethereum, the EVM, the well-defined infrastructure and tools, the critical mass of smart contracts and the tacit knowledge of the developers are the primary reasons to be a type-1 ZK-EVM. This excites us.\n\n### 2\\. Taiko L2 Rollup Node\n\nTaiko nodes get transaction data from Ethereum and execute the transactions on L2, ultimately progressing the state according to the transaction executions. Thus these nodes manage the rollup chain. Currently, the Taiko node is an Ethereum Geth fork.\n\n### 3\\. Taiko Protocol\n\nThe Taiko protocol defines and enforces the rollup rules and defines potential participants. The design upholds the core principles of security, decentralization, and permissionlessness.\n\nSmart contracts deployed on Ethereum L1 act as the data availability mechanism and verifier of the ZK-SNARK proofs. A smart contract deployed on Taiko L2 performs certain important protocol functions we explain in our [whitepaper](https://github.com/taikochain/whitepaper).\n\nIn terms of network participants, we can observe three roles that fit into the above architecture:\n\n1. *Proposers*. Construct rollup blocks from users’ L2 transactions and propose them to L1; any willing participant can perform this block creation function.\n\n2. *Provers*. Generate ZK-SNARK proofs asserting the validity of L2 transactions and blocks out of the aforementioned proposed blocks; any willing participant can perform this proving function.\n\n3. *Node runners*. Execute transactions from on-chain data to stay in sync with the state of the chain. While both Proposers and Provers need to run nodes to fulfill their respective roles, other actors would also run nodes, such as those offering services like a block explorer, and node infrastructure providers. Any willing participant can run Taiko nodes.\n\n**How it works**\n\nBlocks in the Taiko L2 blockchain consist of collections of transactions that are executed sequentially. New blocks can be appended to the chain to update its state, which can be calculated by following the protocol rules for the execution of the transactions.\n\nBlock submission is split into two parts:\n\n1. Block proposal: A block is proposed, with the block data published on Ethereum, and the block appended to the proposed blocks list in the *TaikoL1* contract. The protocol ensures the block is immutable at this point, meaning the block execution is deterministic, and so anyone can calculate the post-execution chain state. We refer to a block and all enclosed transactions at such point as *finalized*. A distinguishable feature in a proposed block on L1 is that there may be invalid transactions that will be skipped over by Taiko L2 nodes. This feature allows for fault-tolerance while multiple blocks are proposed simultaneously.\n\n2. Block verification: Because all proposed blocks are deterministic, blocks can be proven in parallel, since all intermediate states between blocks are known. Once a proof is verified for the block and its correctly-linked parent block is on-chain finalized, we mark the block as *on-chain finalized*.\n\nA fundamental requirement of the protocol is that all data that is necessary to reconstruct the current state, and thus to create and append new blocks, is publicly available on Ethereum. Further, provers can generate proofs for a block using only public data on Ethereum. It is these facts, relying on Ethereum public data and giving all would-be participants a fair playing field, that makes Taiko’s L2 decentralized.\n\nFor in-depth information on the Taiko rollup, please see the [whitepaper](https://github.com/taikochain/whitepaper).\n\nA general truth is that the EVM was not meant to run in a ZK-circuit, and there are plenty of facets of EVM computation and Ethereum data structures and embedded cryptography which are ZK-SNARK-unfriendly and inefficient (slow) to prove. Overcoming these challenges has been the aim of diligent work by many in the field, such as the EF’s PSE. Nonetheless, it remains that generating ZK proofs for EVM computation is slow. This is the main tradeoff opposing compatibility in the different types of ZK-EVMs, with type-1 being slowest with proof generation, but possessing perfect compatibility and future proof-ness. Other types are much faster to generate proofs, but lose differing degrees of EVM/Ethereum-compatibility and future proof-ness.\n\nWhile upholding the non-negotiables of being decentralized, permissionless, and secure - and the priority of complete EVM-equivalence - it is the explicit goal of the Taiko rollup to mitigate the drawbacks of slow proving time via protocol design. That is, the protocol seeks to reach finality quickly, before the ZKPs have been generated. We will continue to design the protocol with such goals in mind, but will also remain open to VM adjustments/optimizations if slow proving drastically degrades user experience of the chain.\n\nWith a brief overview of the technicals complete, let’s move to the human, community aspect of Taiko and Ethereum compatibility. This is extremely important, because after all, blockchains are code-enforced social contracts. It’s ultimately humans and their values-systems that drive the protocols.\n\n## Taiko Tenets\n\nBelow layer-1 is layer-0, the people. Blockchains are built by people, and what these people care about gets baked into the social contract, and into the code and overarching design. As mentioned, here again we seek to have the strongest Ethereum-compatibility.\n\nWe have good reason to stick close to the Ethereum example and specification; it is not solely out of mere love for the protocol and the people. It is because it is the only ecosystem that gives us what we care about, and a shot at changing the world for the better, especially for those who need it most. This sounds lofty, but such are the aims of the Ethereum community, and of Taiko.\n\nBelow we share the Taiko Tenets, three core principles that guide us.\n\n### Accessible\n\nAnyone who wants to use, build on, or participate in Taiko can do so. This is the case because the transaction fees are cheap and throughput is high; the developer experience is robust and Ethereum dapp migration is seamless; the network is permissionless and reuses Ethereum infrastructure to the fullest extent. You can’t have freedom without access.\n\n### Inclusive\n\nTaiko is censorship-resistant and cannot exclude groups or individuals. The rollup is decentralized - relying on Ethereum for data availability and security; and permissionless - allowing any network participant, user, or builder to opt-in. There are no special roles which can censor users/applications/transactions. We are only interested in building credibly neutral, fair systems.\n\n### Open\n\nTaiko is fully open-source and community-centric. We build on the shoulders of giants, and cherish contributing back into Ethereum’s technical progress and community. We value community contributions into the project, harnessing the best minds and ideas that are interested in the space. The type of activity Taiko executes and secures mandates transparency.\n\n## Thank you\n\nThank you for reading. We have been working on Taiko since Q1 2022, with certain teammates contributing to ZK-EVM R&D since 2021, and many more of us working in the scalability and ZK-Rollup space since 2018. We are extremely excited to continue along our journey, as it is our greatest passion and honor to work towards bringing Ethereum to billions of people, securely.\n\nWe’d like to thank many teams and researchers for their phenomenal work on the ZK-EVM and related technologies, including the Ethereum Foundation PSE, Vitalik, Zcash, Aztec, Scroll, and several others.\n\nIn further posts we will go deeper into Taiko’s technical architecture, and share a roadmap with timelines. If you’d like to learn more about Taiko’s rollup protocol right now, you can check out our [whitepaper](https://github.com/taikochain/whitepaper).\n\n## Join us\n\nIf you’d like to join us on our journey in any capacity, we’d love to hear from you. You can apply to join our team by emailing jobs@taiko.xyz, look around and contribute to our [GitHub](https://github.com/taikochain), or join the community via [Discord](https://discord.gg/WqwMUxQEgy), [Twitter](https://twitter.com/taikoxyz), or [Reddit](https://www.reddit.com/r/taiko_xyz/).\n\n\n\n","timestamp":"1665375123","title":"Introduction to Taiko"},"digest":"97qYPn98b84bjYeEMj-V3JfVgZ3_ChqcJGOBepKQiaY","authorship":{"contributor":"0x5b796c4B197B6DfD413f177059C27963EB80af0F","signingKey":"{\"crv\":\"P-256\",\"ext\":true,\"key_ops\":[\"verify\"],\"kty\":\"EC\",\"x\":\"417YNijw0Z5zjDPf2Q9i1IUhgF1yM28_z6QENZ6DdpI\",\"y\":\"_OKtEPfEp1RTmYD5ZlLIL_hd9t1I-ppd8gGmwb5DSrw\"}","signature":"0x719f8ee06a38fdf64a9c94c5708f4e9437aafabda8d6cd83f6d3afd36cee694c3f534e7d07daeead98f51a5eb5b1a0e537d8aa352ed74ff18321e4bf884933271b","signingKeySignature":"pbVGwKYuIYLfAcXWVT9YGCYYTQfvFTjj6MG0Q23gHOfawgF8_lBTY9BrqZuFFW22Bck79u7Wqy3S2M_4Jceo1Q","signingKeyMessage":"I authorize publishing on mirror.xyz from this device using:\n{\"crv\":\"P-256\",\"ext\":true,\"key_ops\":[\"verify\"],\"kty\":\"EC\",\"x\":\"417YNijw0Z5zjDPf2Q9i1IUhgF1yM28_z6QENZ6DdpI\",\"y\":\"_OKtEPfEp1RTmYD5ZlLIL_hd9t1I-ppd8gGmwb5DSrw\"}","algorithm":{"name":"ECDSA","hash":"SHA-256"}},"version":"04-25-2022","wnft":{"chainId":10,"description":"As a type-1 ZK-Rollup, Taiko scales Ethereum in a manner that emulates Ethereum as closely as possible. Learn more about our design in this post.","fee":250,"fundingRecipient":"0x5b796c4B197B6DfD413f177059C27963EB80af0F","imageURI":"bafybeicyqzrlym773jj3i63vc64v2e676d22xnfvytnsat2vcbqjawy3ny","mediaAssetId":235465,"name":"Introduction to Taiko","nonce":8577684,"owner":"0x5b796c4B197B6DfD413f177059C27963EB80af0F","price":0,"proxyAddress":"0x1374F2B5A51334FA0958Db9eA215CCDAE3c967F4","renderer":"0x0000000000000000000000000000000000000000","supply":500,"symbol":"INTRODUCTIONTOTAIKO"},"OriginalDigest":"oRy3ZZ_4-6IEQcuLCMMlxvdH6E-T3_H7UwYVzGDsgf4"},{"content":{"body":"> *This blog post was authored by [d1onys1us](https://twitter.com/indraynor). Follow me on Twitter pl0x.*\n\nTaiko is fully open source -- you can view all the code on [our GitHub](https://github.com/taikoxyz).\n\nBy \"open source\" we mean free to see the source and modify it. Specifically, we use the permissive MIT license for all of our code except our minimally modified geth fork, where we maintain the original GPL license.\n\nHere is a summary of the code powering Taiko:\n\n* Protocol smart contracts\n\n * [taikoxyz/taiko-mono](https://github.com/taikoxyz/taiko-mono): MIT\n\n* L2 node software\n\n * [taikoxyz/taiko-client](https://github.com/taikoxyz/taiko-client): MIT\n\n * [taikoxyz/taiko-geth](https://github.com/taikoxyz/taiko-geth): GPL\n\n* ZK-EVM circuits\n\n * [privacy-scaling-explorations/zkevm-circuits](https://github.com/privacy-scaling-explorations/zkevm-circuits): MIT or Apache 2.0\n\nIn summary, the entire network is open source and unrestricted to join in and participate: the L2 nodes, proposers, provers, and smart contracts on L1/L2.\n\n# MIT vs. GPL\n\nBy GPL, we'll mean GPLv3 for the sake of example, but there are other variants such as AGPLv3, GPLv2, and LGPL -- GPL is more nuanced, as you can see.\n\nThe primary difference between MIT and the GPL is that MIT essentially allows you to do whatever you want, as long as you retain the copyright and permission notice in the codebase. The GPL license imposes a few more restrictions on the developers. For example, using a GPL library in your codebase requires you to convert your entire project under the GPL license, which makes it a \"viral\" license. It also means that you can't create a modified proprietary version.\n\nWhile GPL can be annoying for developers and companies, the idea is that it is nice for users; it gives them the freedom to view the source code. It also prevents someone from running [a modified and possibly malicious version](https://dev.to/ender_minyard/why-i-no-longer-use-the-mit-license-for-new-projects-348m) of the codebase. So this is another way GPL protects the user. GPL, in general, is more concerned with user freedom than the ease of developers using the software.\n\n# Why we went the permissive route\n\nTaiko's guiding principles are:\n\n* Accessible\n\n* Inclusive\n\n* Open\n\nLike all things, these licenses make tradeoffs. For example, someone can convert MIT-licensed code to proprietary code with (potentially malicious) patches. That is a real potential risk for users. On the other hand, GPL-licensed code can exclude developers who don't want to relicense their entire project to GPL just to use a code snippet.\n\nThe reason we chose MIT on this tradeoff was for a similar reason we decided to be a Type 1 ZK-EVM: compatibility and simplicity.\n\nThe MIT license will make it much easier for other people to use our codebase and increases the opportunity for collaboration, which is a part of our DNA. It's also inclusive because it's so short and straightforward. It's easy to understand that you can freely use this code however you want as long as you include the license.\n\n# About user freedom\n\nTo make a final note about GPL, a somewhat controversial license. One could use GPL, specifically the AGPL, in an unethical manner (like making it scary to use and selling another license). It is also undoubtedly more difficult to integrate from the developer's perspective. However, it's always nice to think about one core principle often mentioned by the [Free Software Foundation](https://www.fsf.org/): user freedom.\n\nGiven recent events, we, as developers, must continue thinking about our responsibility to the user. Especially how we should always make it easy for the user to understand and verify our software.\n\nHistorically, some of the worst events have occurred due to a lack of transparency. Therefore, we should strongly encourage openness for the sake of our beloved users. And remember: don't trust, verify.\n\n# Collaborate with us\n\nOkay, so we're all open-source; that's great. Now you want to know how you can contribute. Our [Contributing guide](https://github.com/taikoxyz/taiko-mono/blob/main/CONTRIBUTING.md) is a living document you can reference. It will improve over time.\n\nFor now, here are some specific places to start:\n\n* Reviewing our protocol and offering suggestions on our [GitHub Discussions](https://github.com/taikoxyz/taiko-mono/discussions) or other social platforms.\n\n* Writing educative material for the community to learn more about Taiko and ZK-EVMs.\n\n* Opening issues, we have [templates](https://github.com/taikoxyz/taiko-mono/issues/new/choose) for Bug Reports and Feature Requests.\n\n* Taking on issues, you can find some with the label `good first issue` [here](https://github.com/taikoxyz/taiko-mono/labels/good%20first%20issue).\n\nAny contributor will be featured as a contributor on our README, and be eligible for the 2022 Taiko Contributor (Founding Year) GitPOAP 😎.\n\nThanks for reading!\n\n# Follow us\n\n* Website: [https://taiko.xyz](https://taiko.xyz/)\n\n* Discord: \n\n* GitHub: \n\n* Twitter: \n\n* 🥁 Join us 🍗: ","timestamp":"1669933221","title":"Taiko is fully open source"},"digest":"yBCa4zKyXz2lNeeoq9oz-NGlp1So-Fv4Gu0CVkp38uQ","authorship":{"contributor":"0x2b1F13149C7F89622BBfB46Ae1e3ECc573Bb9331","signingKey":"{\"crv\":\"P-256\",\"ext\":true,\"key_ops\":[\"verify\"],\"kty\":\"EC\",\"x\":\"HA2ZeLg0lRobJHRdlR8czM8AM9LMpqyITWkPE1pLAfk\",\"y\":\"UZ7neopFenRB5_MnTbpxeQ_1nBMowb-4wP29Kzr6ha4\"}","signature":"0x06bef07adaa4cee886c6772fb36591c616ff5f6ee07f2d99e08850d283f4ab8413596d1580dda2fb00144fb8cfbbf6b37dcf2fdcf54ea5baa76db9773014c1f21c","signingKeySignature":"_bV4CgKVZnYvaJ_yXVn8ZXgzzmPiaZH7FpY-mdI2ppd6ntXU8-8BBnvT-1RJ3RSFo0rndV0OWuO1cT6kVqyZKw","signingKeyMessage":"I authorize publishing on mirror.xyz from this device using:\n{\"crv\":\"P-256\",\"ext\":true,\"key_ops\":[\"verify\"],\"kty\":\"EC\",\"x\":\"HA2ZeLg0lRobJHRdlR8czM8AM9LMpqyITWkPE1pLAfk\",\"y\":\"UZ7neopFenRB5_MnTbpxeQ_1nBMowb-4wP29Kzr6ha4\"}","algorithm":{"name":"ECDSA","hash":"SHA-256"}},"version":"04-25-2022","wnft":{"chainId":10,"description":"Taiko is fully open source -- you can view all the code on our GitHub.\n\nBy \"open source\" we mean free to see the source and modify it.","fee":250,"fundingRecipient":"0x5b796c4B197B6DfD413f177059C27963EB80af0F","imageURI":"QmUzJLXqxyq4StZoYfxfqLxU1kLdN3yJfphqXignD24Yd8","mediaAssetId":298408,"name":"Taiko is fully open source","nonce":349407,"owner":"0x2b1F13149C7F89622BBfB46Ae1e3ECc573Bb9331","price":0,"proxyAddress":"0xD7BB89c0eC6AC6a0Ec4E5A8a0B32f8bDF299409e","renderer":"0x0000000000000000000000000000000000000000","supply":500,"symbol":"TAIKOISFULLYOPENSOURCE"},"OriginalDigest":"31vzkwgNaKNrze0oIv_wTKCw6Tha8OYQ6ffrquS3XUg"},{"content":{"body":"Today, the Taiko Alpha-1 testnet (a1) is live - our first public testnet! We’ve codenamed this testnet, **Snæfellsjökull**. Be on the lookout for other Icelandic volcano releases as we approach mainnet over 2023! 🌋 \n\nWe’re thrilled to reach this milestone towards our Type-1 ZK-EVM, with the ultimate goal of scaling Ethereum in a manner that is as secure and seamless for developers and users as possible. We still have a long way to go, but we hope you will join us in using and testing our first public testnet release.\n\nIf you want to jump right in, you can head to the testnet guide here: \n\n\n\nIf you want to learn more about what is in this release, and what is not, read on.\n\n![https://taiko.xyz/docs/category/alpha-1-testnet-guide](https://images.mirror-media.xyz/publication-images/W0LFjBfCqJdV7VA_duPVb.jpg?height=1832&width=2752)\n\nTaiko has been committed to building in the open, and our [GitHub](https://github.com/taikoxyz) has reflected this for some time with everything being open source. In that vein, this first public testnet is as open as we can make it. It is open to all developers to deploy contracts on, all users to test out, and all willing participants to run an L2 node and propose blocks.\n\n## About the Taiko Alpha-1 testnet (Snæfellsjökull)\n\n* **Open to all developers** to [deploy smart contracts](https://taiko.xyz/docs/alpha-1-testnet/deploy-a-contract). As Taiko aims to be a type-1 ZK-EVM (Ethereum-equivalent), you can use all the Ethereum/solidity tooling you know and love.\n\n* **Open to all users** who want to use it and play around with some transactions.\n\n* **Open to all interested parties** to [run an L2 node](https://taiko.xyz/docs/alpha-1-testnet/run-a-node), including as a proposer! Taiko will be running some nodes and proposing blocks, and we hope you will join us.\n\n* The L1 environment is a private Ethereum PoA fork that Taiko runs (testnet L1).\n\n* Faucet for requesting ETH and a sample ERC20 token on Taiko testnet [L2](https://l2faucet.a1.taiko.xyz/) and [L1](https://l1faucet.a1.taiko.xyz/).\n\n* [Bridge](https://bridge.a1.taiko.xyz/) to move assets between testnet L2 and L1.\n\n* Block explorers to view assets and activity on testnet [L2](https://l2explorer.a1.taiko.xyz/) and [L1](https://l1explorer.a1.taiko.xyz/).\n\n## What is not in this testnet\n\n* Ability to become a prover. You cannot extend your node into a prover. \n\n* Validity proofs. There will be no ZKPs generated in this testnet release.\n\n* Pre-deployed dapps. Bridging between L2 and L1 and transferring ETH or ERC20 to friends are the only supported user actions out-of-the-box. Any developer can deploy their smart contract or dapp, though, making it available to all users.\n\n## Get involved\n\nOnce more, here is the testnet guide where you can find documentation and links to all relevant apps/tools for testnet usage:\n\n\n\nBesides deploying, using, and running, there are plenty of other ways you can get involved and help Taiko improve. Some of these include:\n\n* [Provide feedback](https://github.com/orgs/taikoxyz/discussions/new?category=feedback&title=Testnet%20feedback%20form&body=%23+Friction+log%0D%0A-+TODO%0D%0A%0D%0A%23+Other+notes%0D%0A-+TODO%0D%0A) on any bugs or friction you come across, or anything you find may be helpful.\n\n* Create tutorials or other content that can help developers and users get started.\n\nHearing from you all is the reason we have been keen to release this testnet as early as possible. On that note, we will have our **first-ever community call on Thursday, December 29th at 15:00 UTC on our Discord server**. You can find the call channel [here](https://discord.gg/taikoxyz?event=1057323602678124576) and signal your interest to join. We will be providing general updates, but also invite questions in AMA style. Please ask any questions you would like in the “community-call-questions” [Discord](https://discord.gg/taikoxyz) channel in advance.\n\nWe also want to commemorate this moment on Snæfellsjökull with all of you 🙂. As a result, we will be minting a POAP for all users of the testnet prior to January 31st 23:59 UTC. Any user with a bridging transaction + one other type of transaction (transfer, dapp tx) will receive one. They will be issued in the month of February.\n\n## Thank you\n\nFinally, we want to say a sincere thank you. We have tons of people to thank, as this journey has been a year in the making or longer for some. We will specifically thank the Ethereum Foundation’s Privacy & Scaling Exploration team for their ZK-EVM work, along with all contributors to that effort. We thank the incredible Taiko community and our early supporters who have contributed from the beginning, and of course the broader Ethereum community who have done the same.\n\n### Join us\n\nExplore open positions on our [job board](https://www.notion.so/Taiko-Jobs-828fd7232d2c4150a11e10c8baa910a2).\n\n### Follow us\n\nTo stay updated on the latest from Taiko:\n\n* Website: [https://taiko.xyz](https://taiko.xyz/)\n\n* Discord: \n\n* GitHub: \n\n* Reddit: \n\n* Twitter: \n\n### Contribute\n\nContribute to Taiko and earn a GitPOAP! You will also be featured as a contributor on our README. Get started with the [contributing guide](https://github.com/taikoxyz/taiko-mono/blob/main/CONTRIBUTING.md).","timestamp":"1672160691","title":"Taiko Alpha-1 Testnet is Live"},"digest":"du92fke7V7XDdgHqbG1Dhytzn2XhwG408dR78CN1POI","authorship":{"contributor":"0x381636D0E4eD0fa6aCF07D8fd821909Fb63c0d10","signingKey":"{\"crv\":\"P-256\",\"ext\":true,\"key_ops\":[\"verify\"],\"kty\":\"EC\",\"x\":\"4zcQdnWNxHeBOOkRLGozl2oI_rBZTg8bVaZ2Xq8sbN8\",\"y\":\"U31TF_BfLJEX_XcNt7KIjaZDA8p7AHVPq98KRKlPo9k\"}","signature":"0xb33f23c84df31b4e60e24957fa51e2af571b008e75d57f8064ddbaed204f248573f2433feaa93d2a13756d1b8b8123ffb836b949c53e79aad462745aef125a621c","signingKeySignature":"EEvOuH-jYBd2YuJGDbSWuPZFks-kqf7U0LleZdkwUQ7JuZQE7qDyFf5NTNWKFu_5qqbhVTh96Q9IX9wodE_y4g","signingKeyMessage":"I authorize publishing on mirror.xyz from this device using:\n{\"crv\":\"P-256\",\"ext\":true,\"key_ops\":[\"verify\"],\"kty\":\"EC\",\"x\":\"4zcQdnWNxHeBOOkRLGozl2oI_rBZTg8bVaZ2Xq8sbN8\",\"y\":\"U31TF_BfLJEX_XcNt7KIjaZDA8p7AHVPq98KRKlPo9k\"}","algorithm":{"name":"ECDSA","hash":"SHA-256"}},"version":"04-25-2022","wnft":{"chainId":10,"description":"Today, the Taiko Alpha-1 testnet (a1) is live - our first public testnet! We’ve codenamed this testnet, Snæfellsjökull. Be on the lookout for other Icelandic volcano releases as we approach mainnet over 2023! 🌋\n","fee":250,"fundingRecipient":"0x5b796c4B197B6DfD413f177059C27963EB80af0F","imageURI":"QmTKWBRvETAS5Mr7rvMwyDRNbtGc161sv99wyDmQF8EG1N","mediaAssetId":328375,"name":"Taiko Alpha-1 Testnet is Live","nonce":7690614,"owner":"0x381636D0E4eD0fa6aCF07D8fd821909Fb63c0d10","price":0,"proxyAddress":"0xf0847b3B3EffD493D50e0388FF55D76300732cc9","renderer":"0x0000000000000000000000000000000000000000","supply":500,"symbol":"TAIKOALPHA-1TESTNETISLIVE"},"OriginalDigest":"-lahy4KbGkeAcqhs0ETG3Up3oTVzZ0wLoE1eK_ao5h4"},{"content":{"body":"Ethereum has come a long way in its seven-year life — changing the world, in our opinion — but it is only just getting started.\n\nScaling Ethereum at a technical level, as ZK-EVMs aim to do, is just one (huge) part of the equation in bringing it to the world - there is also the need to… actually bring it to the world!\n\nThat’s why we are initiating the **Taiko Ambassador Program**.\n\nWe need help in spreading the word that Ethereum scales securely and that you can use your existing solidity code, dapp, toolchain, or product with an Ethereum-equivalent ZK-Rollup. If you are interested in joining us in this effort, we welcome your participation.\n\n## You can fulfill one or several functions:\n\n* Developer advocacy and relations\n\n* Educational content creator\n\n* Community organizer \n\nSome ambassadors may focus strictly on developer goals, some on community awareness, some on a mix.\n\n> The mandate of the ambassador is to assist, advocate, and educate within the community of Ethereum/Taiko developers and users. Given this is the first iteration of the program, you may help shape the program as much as you participate in it.\n\n## You should consider applying if:\n\n* You are a developer or researcher experienced or interested in Ethereum and ZKPs, and have the ability and desire to teach, communicate, and facilitate the experience of other developers.\n\n* You are not a developer or researcher, but have a strong understanding of Ethereum and ZKPs, and an aptitude for educating people and/or community organization.\n\n* You are a clear communicator, possess patience, and have a strong desire to move the needle on whatever you participate in.\n\n## You can expect the following from the program:\n\n* Ability to work closely with the team and community to achieve the above-articulated goals\n\n* Monthly rewards\n\n* Ability to progress to a full-time role within Taiko Labs\n\n## Apply here\n\n🥁 Here is the application form: 🥁\n\nApplications will remain open until **Friday, January 13, 23:59 UTC**. We will seek to onboard approximately 2 to 4 ambassadors in this first cohort and will re-open the program again once we have some feedback and more capacity.\n\nThank you in advance for your interest in helping scale Ethereum and Taiko, we look forward to welcoming you!\n\n### Join us\n\nExplore open positions on our [job board](https://www.notion.so/Taiko-Jobs-828fd7232d2c4150a11e10c8baa910a2).\n\n### Follow us\n\nTo stay updated on the latest from Taiko:\n\n* Website: [https://taiko.xyz](https://taiko.xyz/)\n\n* Discord: \n\n* GitHub: \n\n* Reddit: \n\n* Twitter: \n\n### Contribute\n\nContribute to Taiko and earn a GitPOAP! You will also be featured as a contributor on our README. Get started with the [contributing guide](https://github.com/taikoxyz/taiko-mono/blob/main/CONTRIBUTING.md).","timestamp":"1672862542","title":"Taiko Ambassador Program"},"digest":"weGZlAWcC741tTvAnGXGQt9Ep2Rkgl6LITpJ3IomBII","authorship":{"contributor":"0x381636D0E4eD0fa6aCF07D8fd821909Fb63c0d10","signingKey":"{\"crv\":\"P-256\",\"ext\":true,\"key_ops\":[\"verify\"],\"kty\":\"EC\",\"x\":\"0iMX67LQd6Qb7GP9n3SZ1-65HExs3_B31V9iMmD4ToY\",\"y\":\"LZJ_7eeo-lETUES8GabDJOa9VdDaCBFmrIbMwvw-QFo\"}","signature":"0x1294f77d45afcb00255721849b937e76f376d689db5fd1a059fcbf3c29c1e74057e35aeac789c7639405cac3007638d694cf42610c19907889da636d45dc8c4d1c","signingKeySignature":"BHjFcB26pc1W9z9r9S0isQEzMAMr2m_RLZB-sc-drDe23SL9dnchLSbAYKgrcAsZhc-2sPb4wHhcfAbrpEF3Tw","signingKeyMessage":"I authorize publishing on mirror.xyz from this device using:\n{\"crv\":\"P-256\",\"ext\":true,\"key_ops\":[\"verify\"],\"kty\":\"EC\",\"x\":\"0iMX67LQd6Qb7GP9n3SZ1-65HExs3_B31V9iMmD4ToY\",\"y\":\"LZJ_7eeo-lETUES8GabDJOa9VdDaCBFmrIbMwvw-QFo\"}","algorithm":{"name":"ECDSA","hash":"SHA-256"}},"version":"04-25-2022","wnft":{"chainId":10,"description":"Ethereum has come a long way in its seven-year life — changing the world, in our opinion — but it is only just getting started.\n","fee":250,"fundingRecipient":"0x5b796c4B197B6DfD413f177059C27963EB80af0F","imageURI":"QmcM2j9R4R6CCJhgp9FBQpQL65ySf4L73HZpNZEmgH7B5Z","mediaAssetId":336972,"name":"Taiko Ambassador Program","nonce":9848835,"owner":"0x381636D0E4eD0fa6aCF07D8fd821909Fb63c0d10","price":0,"proxyAddress":"0x55683134E85eaf3abDaF7B57347ED2e77668804d","renderer":"0x0000000000000000000000000000000000000000","supply":500,"symbol":"TAIKOAMBASSADORPROGRAM"},"OriginalDigest":"BvcEyYeVIiHnjc-i5qf3zR4s67Jc6nz_R6OSGj5rzOE"},{"content":{"body":"Taiko is building a Type 1 (Ethereum-equivalent) ZK-EVM. What benefits come from using a Type 1 ZK-EVM? To answer this, we need to understand the changes a ZK-EVM can make at various levels and the tradeoffs they incur. Let’s learn together.\n\nThis post makes a few assumptions about your understanding of Ethereum. We are going to suggest that you first understand the following:\n\n* What a [ZK-EVM](https://ethereum.org/en/developers/docs/scaling/zk-rollups/) (EVM-compatible ZK-Rollup) is at a high level\n\n* How Ethereum stores data in the form of a [Merkle Patricia Tree](https://ethereum.org/en/developers/docs/data-structures-and-encoding/patricia-merkle-trie/) and uses Merkle proofs\n\n* How smart contracts price their execution with a [concept of gas](https://ethereum.org/en/developers/docs/gas/)\n\n* The [different types of ZK-EVMs](https://vitalik.ca/general/2022/08/04/zkevm.html)\n\nWith that out of the way, here are the five questions we’ll be exploring:\n\n* [What is a Type 1 ZK-EVM?](https://www.notion.so/The-Type-1-ZK-EVM-82b1886f4cc44061bc35b1d54d4a52da)\n\n* [What does a Type 2+ ZK-EVM change?](https://www.notion.so/The-Type-1-ZK-EVM-82b1886f4cc44061bc35b1d54d4a52da)\n\n* [What are the impacts of these changes?](https://www.notion.so/The-Type-1-ZK-EVM-82b1886f4cc44061bc35b1d54d4a52da)\n\n* [Why does proof generation cost matter?](https://www.notion.so/The-Type-1-ZK-EVM-82b1886f4cc44061bc35b1d54d4a52da)\n\n* [Why use a Type 1 ZK-EVM?](https://www.notion.so/The-Type-1-ZK-EVM-82b1886f4cc44061bc35b1d54d4a52da)\n\n## What is a Type 1 ZK-EVM?\n\nOne way to think of the different types of ZK-EVMs is by their proximity to Ethereum’s architecture at the base layer, such as:\n\n* The usage of a Merkle Patricia Tree for the [various state trees](https://medium.com/@eiki1212/ethereum-state-trie-architecture-explained-a30237009d4e)\n\n* The [execution client specification](https://ethereum.org/en/developers/docs/nodes-and-clients/)\n\n* The [amount of gas each opcode uses](https://ethereum.org/en/developers/docs/evm/opcodes/)\n\n![Adapted from https://vitalik.ca/general/2022/08/04/zkevm.htmled from ](https://i.imgur.com/4e3Dvgx.png)\n\nThe different types of ZK-EVMs make tradeoffs between compatibility and proof generation cost. A Type 1 ZK-EVM prioritizes compatibility over proof generation cost.\n\nAnother term for Type 1 ZK-EVMs is “Ethereum-equivalent”. This term comes from the fact that Type 1 ZK-EVMs make no changes to the Ethereum architecture, whether it be the hash function, state trees, or gas costs. This equivalency allows us to reuse execution clients with minimal modification.\n\n## What does a Type 2+ ZK-EVM change?\n\nIn this post, when we say Type 2+, we are referring to Type 2/2.5 ZK-EVMs. Type 3/4 ZK-EVMs are [not quite EVM-equivalent](https://vitalik.ca/general/2022/08/04/zkevm.html), so we’ll put them aside for the discussions of this post.\n\nType 2+ ZK-EVMs change parts of the Ethereum stack which are complex to prove. The changes might include:\n\n* Changing gas costs for ZK-unfriendly operations\n\n* Changing the Keccak hash function to a more ZK-friendly one\n\nThese changes result in lower proof generation costs while maintaining bytecode level compatibility, but they could also have some other impacts.\n\n## What are the impacts of these changes?\n\nLet’s break this down via examples to paint a clearer picture of how these changes could impact you as a smart contract developer.\n\n### 1\\. Security mechanisms could change\n\nA classic example of using [gas as a security mechanism](https://consensys.net/diligence/blog/2018/12/silent-but-vulnerable-ethereum-gas-security-concerns/) is setting a fixed gas limit for an ETH transfer so that state changes are not possible in the destination address. Smart contracts that rely on this for security will no longer be secure if gas costs are changed, which would allow state changes to occur. Another scenario arises if Keccak hashes get super expensive, and the security of the smart contract depends on a minimum number of hashes to be possible (like for a fraud-proof).\n\n### 2\\. Changing gas costs could have side effects\n\nIf your smart contract is optimized for gas costs as specified on Ethereum L1, changing these gas costs could cause the contract to use more gas than intended. You also might be using [tools to fine-tune the gas usage](https://github.com/cgewecke/hardhat-gas-reporter) in your contract, and changing gas costs could break those tools. Additionally, increasing gas costs could cause the contract to exceed the block gas limit. For example, if the contract frequently uses the Keccak opcode, the developer might need to find more gas-efficient ways to get things done or change the hash function.\n\n### 3\\. Changing the block hash could have side effects\n\nA Type 2+ ZK-EVM might use a different hash function — and produce different state roots. This change could break compatibility for smart contracts that rely on the block hash. For example, a bridge contract might [use a Merkle proof for verification](https://eips.ethereum.org/EIPS/eip-1186), and changing the hash function from Keccak to something else would break these proofs. Relying on the block hash this way would also break with the introduction of Verkle trees. Hopefully, we can have an abstracted precompile to use in the future.\n\n### You could lose some nice features of Keccak\n\nThe [Keccak hash function](https://academy.binance.com/en/glossary/keccak) is widely accepted as a battle-tested and secure hash function, so changing it for an alternative could be risky. Additionally, Keccak has much faster native performance and lower gas fees when compared to some more ZK-friendly hash functions, such as [Poseidon](https://www.poseidon-hash.info/).\n\n## Why does proof generation cost matter?\n\nA higher proof generation cost can be seen as a negative for a few reasons:\n\n* A potentially longer time to finality\n\n* Imbalances the ratio between gas cost and proof generation cost\n\n* More expensive transactions\n\nWe are not concerned about the longer time to finality because we achieve instant finality through our protocol design, by circumventing the need to wait for a proof when on the rollup (proposed blocks have the same finality as the enclosing Ethereum L1 block, see: [Layer 2 Finality](https://hackmd.io/@taikolabs/HkN7GR64i#/)). In the case where a proof is needed, such as moving assets to another layer, we are optimistic about [new methods for bridging that don’t require a full proof](https://twitter.com/VitalikButerin/status/1588708049359089664?s=20&t=OZpu9KpHJQDWGu_X2MnXxw).\n\nThe ratio between gas cost and proof generation cost matters because a malicious actor could submit blocks that are cheap in gas but expensive to generate a proof for (DOS attack). Mitigating this attack vector is a more extended topic, so we’ll go deeper into our proposed solution in a subsequent post.\n\nIn general, we are looking forward to future improvements in proof generation costs, which will decrease the cost of transactions:\n\n* Prover-level optimizations like [Hyperplonk](https://www.espressosys.com/blog/hyperplonk-a-zk-proof-system-for-zkevms) and [Caulk](https://eprint.iacr.org/2022/621.pdf)\n\n* [General optimizations & tricks](https://docs.google.com/presentation/d/1eHVzLPRIEziCJ_oDuJG0yZ-5klNj_daqioC0UaGDaiw/edit?usp=sharing)\n\n* [Community focus toward a fully SNARKed Ethereum](https://twitter.com/VitalikButerin/status/1588669782471368704?s=20&t=nMFRL5j5Ffal66NMtJ_6KA)\n\n* ZKP-specific hardware\n\n## Why use a Type 1 ZK-EVM?\n\nThe main advantage of using a Type 1 ZK-EVM is that you can give it a try without any upfront costs — you don’t need to make any changes to your code or development environment. You can prototype, develop, test, audit, and deploy on Ethereum L1 first and migrate to Taiko later. Alternatively, you can develop on Taiko and then migrate to L1 or another EVM-equivalent chain at any time.\n\nA Type 1 ZK-EVM is a continual development process. It means not only being Ethereum-equivalent now but continuing to inherit future Ethereum upgrades. Staying Type 1 restrains us from adding features that would break our Ethereum-equivalence. It also encourages us to contribute upstream improvements to Ethereum L1.\n\nThank you for reading! 🥁\n\n## Links\n\n* Website (with whitepaper): \n\n* Discord: \n\n* GitHub: \n\n* Twitter: \n\n* Join us: [https://taikochain.notion.site/Taiko-Jobs-828fd7232d2c4150a11e10c8baa910a2](https://www.notion.so/Taiko-Jobs-828fd7232d2c4150a11e10c8baa910a2)\n\n## Sources\n\n* \n\n* \n\n* \n\n* \n\n* \n\n* \n\n* \n\n* [h](https://ethereum.org/en/developers/docs/data-structures-and-encoding/patricia-merkle-trie/)[ttps://medium.com/@eiki1212/ethereum-state-trie-architecture-explained-a30237009d4e](https://medium.com/@eiki1212/ethereum-state-trie-architecture-explained-a30237009d4e)\n\n* \n\n* ","timestamp":"1668488929","title":"The Type 1 ZK-EVM"},"digest":"NYZmLd1IDnfDtmDgswgncq6OZdQ_enKOqG-Fx-8qvBs","authorship":{"contributor":"0x5b796c4B197B6DfD413f177059C27963EB80af0F","signingKey":"{\"crv\":\"P-256\",\"ext\":true,\"key_ops\":[\"verify\"],\"kty\":\"EC\",\"x\":\"LjnohJiDajcEHC7X2CCVVF_AZ0C5BXROU-_c0BX0W2E\",\"y\":\"5GXvglTR44CtJxjys2BipccOAm-tZ9jwFXVkuMDJHbI\"}","signature":"0x4f0c4d1fdbd2e2adc247b91603f6bb0fa4198af82a7e9c56cde27224796b69602e30325bde92ca548289160db43ae74ba2f53d3cf0f1bb562a89403709bc34af1c","signingKeySignature":"FY1OhIn2pRb6ezJCs4oQYrrXNXLWV4uTA4qYPdUjHxU3D64yhTz0Vz6cbkk5CAjVvDWx3mCknfOK0flucz0Rrw","signingKeyMessage":"I authorize publishing on mirror.xyz from this device using:\n{\"crv\":\"P-256\",\"ext\":true,\"key_ops\":[\"verify\"],\"kty\":\"EC\",\"x\":\"LjnohJiDajcEHC7X2CCVVF_AZ0C5BXROU-_c0BX0W2E\",\"y\":\"5GXvglTR44CtJxjys2BipccOAm-tZ9jwFXVkuMDJHbI\"}","algorithm":{"name":"ECDSA","hash":"SHA-256"}},"version":"04-25-2022","wnft":{"chainId":10,"description":"Taiko is building a Type 1 (Ethereum-equivalent) ZK-EVM. What benefits come from using a Type 1 ZK-EVM? To answer this, we need to understand the changes a ZK-EVM can make at various levels and the tradeoffs they incur. Let’s learn together.\n","fee":250,"fundingRecipient":"0x5b796c4B197B6DfD413f177059C27963EB80af0F","imageURI":"bafybeie74reb3nc2w7xawlcczmaiih3op6oxtyf4ygibqmjkxbsrsw7jhi","mediaAssetId":279205,"name":"The Type 1 ZK-EVM","nonce":8051681,"owner":"0x5b796c4B197B6DfD413f177059C27963EB80af0F","price":0,"proxyAddress":"0x8AD8968e2f1E929B3c1571361BC074c5d7efb15E","renderer":"0x0000000000000000000000000000000000000000","supply":500,"symbol":"THETYPE1ZK-EVM"},"OriginalDigest":"w7NSKDeKfJoEy0p89I9feixKfdK-20JgWF9HZzxfeBo"},{"content":{"body":"Below is our brief summary of what happened in the fourth quarter of 2022. It was a super busy one to close out the year, and now we are excited to be writing from 2023 - the year where ZK-EVMs are sure to leave an indelible mark on Ethereum and the world. Let’s jump right in.\n\n## Research & Development\n\n### ZK-EVM\n\n* Implemented RETURNDATASIZE/RETURNDATACOPY.\n\n* Added circuit benchmarks.\n\n* Added unit tests for math gadgets/super circuit.\n\n* Added support for invalid transactions.\n\n* Refactored math gadgets.\n\n* Made improvements to MPT circuit.\n\n* Investigated caulk, hyperplonk and plonky2.\n\n### Client & Testnet\n\n* Created `simple-taiko-node` for running a Taiko node with a simple command, inspired by `simple-optimism-node`.\n\n* Created a guide documenting how to use the testnet.\n\n* Launched faucets and block explorers for interacting with the testnet.\n\n### Bridge\n\n* Implemented a functional bridge relayer in Go.\n\n* Implemented a web UI to integrate with the relayer and bridge smart contracts.\n\n### Protocol\n\n* Fixed a bug in the Bridge contract that allows anyone to disable destination chains.\n\n* Fixed a bug in `getProposedBlock` with boundary checks.\n\n* Refactored the Bridge contract to persist the message status in known storage slots for easier generation of Merkle proofs.\n\n* Exposed more data from the core protocol such as `getUncleProofDelay`, `getBlockProvers`, and `getLatestSyncedHeader`.\n\n* Merged the first tokenomics implementation into the core protocol.\n\n* Forced invalidBlock to have the latest verified block as the parent and also force the transactor to be the golden touch address with 0 gas-price.\n\n* Fixed a bug in TokenVault contract with respect to `msg.value`.\n\n* Changed the core protocol rules to allow empty blocks (blocks with only an anchor transaction).\n\n* Add a Failed Bridge message status to allow future token releasing from the source bridge contract.\n\n* To increase readability, we now call a block “verified” when it is actually finalized on chain. Previous the status is called “finalized” which is confusing sometimes.\n\n* Removed proposer and prover whitelisting from the core protocol implementation to enable the next fully permissionless testnet.\n\n* Moved away from *yarn* and adopted *pnpm*\n\n* Introduced a lot of small improvements on the core protocol implementation.\n\n> All of the above is open source. To learn more or contribute, please visit our [GitHub](https://github.com/taikoxyz).\n\n## Operations & Community\n\nWe [launched our Alpha-1 public testnet, Snæfellsjökull](https://mirror.xyz/labs.taiko.eth/-lahy4KbGkeAcqhs0ETG3Up3oTVzZ0wLoE1eK_ao5h4). The launch happened in late December and participation was several times greater than expected — across all metrics. The testnet was open to all developers to deploy contracts; all users to bridge and perform other transactions; and all willing participants to run an L2 node and act as a proposer. A huge thank you to all who helped test it and make it a smashing success.\n\n![](https://images.mirror-media.xyz/publication-images/MyZWBeL6rbxcBfGiR9w_s.png?height=1974&width=2834)\n\nWe will share many stats about the testnet closer to its end, but for now we’d like to highlight that over 2000 proposers have proposed L2 blocks! Thank you.\n\n### Community grew significantly\n\nThe community grew throughout the quarter, with a big growth spurt in December around the testnet. Our [Twitter](https://twitter.com/taikoxyz) following has reached over 25K, and our [Discord](https://discord.gg/taikoxyz) has reached over 30K members! Welcome, new folks! 👋\n\nTo keep up with the growth of the lively and incredible community, we onboarded new moderators in Discord. Shout out and much love to ex_scxr, blank, helios, and lepaluddi! We still welcome community members to help out and get involved, so don’t be shy to reach out. The community also went truly global with multi-language channels in the Discord, so we will need multi-language help going forward.\n\n### Contributors helped meaningfully\n\nBeyond helping coordinate the community, there are tons of other ways to contribute, especially since all of Taiko became [fully open source](https://mirror.xyz/labs.taiko.eth/31vzkwgNaKNrze0oIv_wTKCw6Tha8OYQ6ffrquS3XUg) during the quarter. So whether you want to learn from, contribute, or fork any part of the codebase, please go ahead!\n\nTo make it as easy as possible to contribute, we wrote a [contribution guide](https://github.com/taikoxyz/taiko-mono/blob/main/CONTRIBUTING.md) covering coding standards, documentation standards/requests, and how you can earn a GitPOAP for your GitHub contributions to Taiko.\n\n### Team and extended-team expands\n\nFor those wanting to make contributing more of a full-time effort, we created a [careers page](/828fd7232d2c4150a11e10c8baa910a2) with several open positions we continue to hire for across engineering and operations.\n\nWe also launched the [Taiko Ambassador Program](https://mirror.xyz/labs.taiko.eth/BvcEyYeVIiHnjc-i5qf3zR4s67Jc6nz_R6OSGj5rzOE) to bring in talented developer advocates, community educators, and more. (Okay, technically this happened in Januray so not Q4 but wtvr.) We received over 1800 applications and are still going through them, so please hang tight! As mentioned, we only aim to onboard 2 to 4 Ambassadors in this first cohort, so if you don’t get onboard this time, please don’t be discouraged, there is always next cohort, and still plenty of ways to get involved and contribute outside that program.\n\n### Educated the community\n\nWe also wrote several educational blog posts covering topics such as [Type-1 ZK-EVMs](https://mirror.xyz/labs.taiko.eth/w7NSKDeKfJoEy0p89I9feixKfdK-20JgWF9HZzxfeBo) and [Rollup Decentralization](https://mirror.xyz/labs.taiko.eth/sxR3iKyD-GvTuyI9moCg4_ggDI4E4CqnvhdwRq5yL0A).\n\nOf course, the education didn’t stop with the blog, but took place across the [Taiko website](https://taiko.xyz/) which sports a new and improved look, and the same goes for our [documentation](https://taiko.xyz/docs/intro). Education also happened in-person, with a few presentations in Colombia and Portugal on the topics of [Layer-2 Finality](https://hackmd.io/@taikolabs/HkN7GR64i) and [Taiko Overview and Optimizations](https://hackmd.io/@taikolabs/S1haywHIj).\n\nWe had our first [community call](https://youtu.be/6wvd3gbcTTw) where several team members gave updates and answered questions to a packed house of over 2400 attendees! Looking forward to seeing you again at the next one.\n\n### Ecosystem development\n\nWith our first public testnet launched and quite overwhelming node, proposer, and user participation, our next focus is definitely growing our developer community! With that in mind, you will see Taiko’s presence at upcoming Ethereum ecosystem events, developer conferences, and hackathons. We look forward to meeting you all and helping scale Ethereum together.\n\n## Thank You\n\nAs you can tell, it was an exciting and important quarter for Taiko. As you can also tell, it was a team-wide and community-wide effort. None of this matters without empowering a broad community of developers, users, network participants and advocates — so a heartfelt thank you to all of you. We still have tons of work to do to scale Ethereum securely, let’s get it!\n\n### Join us\n\nExplore open positions on our [job board](https://www.notion.so/Taiko-Jobs-828fd7232d2c4150a11e10c8baa910a2).\n\n### Follow us\n\nTo stay updated on the latest from Taiko:\n\n* Website: [https://taiko.xyz](https://taiko.xyz/)\n\n* Discord: \n\n* GitHub: \n\n* Reddit: \n\n* Twitter: \n\n### Contribute\n\nContribute to Taiko and earn a GitPOAP! You will also be featured as a contributor on our README. Get started with the [contributing guide](https://github.com/taikoxyz/taiko-mono/blob/main/CONTRIBUTING.md).","timestamp":"1674500168","title":"Taiko Community Update — Q4/2022"},"digest":"jZDYA2FH7mgmCKSp_5xtLNCuO4fzoiC4LTdLpgHfUkU","authorship":{"contributor":"0x381636D0E4eD0fa6aCF07D8fd821909Fb63c0d10","signingKey":"{\"crv\":\"P-256\",\"ext\":true,\"key_ops\":[\"verify\"],\"kty\":\"EC\",\"x\":\"MH__-7G6Mn-OQkM_R8qyte-zM3nAbmt5Ji7rnqoQJzs\",\"y\":\"WTh6P8e0bgnDpFeNspkzcG0itWLKOhXNT8lUIND1lSE\"}","signature":"0xcd7827ffc43c64af46c1c28dd3dde2ac9cc8152a768c16db5db9639d9ea944f108a749eb840b8a72dddc9a701acfac627ad490230342a3b5b760eb9f3b540ea01c","signingKeySignature":"Dk25pgwk0aAIVSCdJ_mbmfMo3t0NWzYk_bBb38P1sp0r6qkulFLl7pXuF8PtUuZ2Y7l9n5ooKjS5cwxUEaGvIQ","signingKeyMessage":"I authorize publishing on mirror.xyz from this device using:\n{\"crv\":\"P-256\",\"ext\":true,\"key_ops\":[\"verify\"],\"kty\":\"EC\",\"x\":\"MH__-7G6Mn-OQkM_R8qyte-zM3nAbmt5Ji7rnqoQJzs\",\"y\":\"WTh6P8e0bgnDpFeNspkzcG0itWLKOhXNT8lUIND1lSE\"}","algorithm":{"name":"ECDSA","hash":"SHA-256"}},"version":"04-25-2022","wnft":{"chainId":10,"description":"Below is a brief summary of Taiko updates from Q4 2022. Now, 2023 is when ZK-EVMs are sure to leave an indelible mark on Ethereum and the world.","fee":250,"fundingRecipient":"0x5b796c4B197B6DfD413f177059C27963EB80af0F","imageURI":"QmeN9jeFWF4TnH6L9xCHPmvkodbWc83ex2yxvHzpvsfSmT","mediaAssetId":356760,"name":"Taiko Community Update — Q4/2022","nonce":5698305,"owner":"0x381636D0E4eD0fa6aCF07D8fd821909Fb63c0d10","price":0,"proxyAddress":"0xf1E81d367386cc01f4021b894B9e34DfAC953158","renderer":"0x0000000000000000000000000000000000000000","supply":500,"symbol":"TAIKOCOMMUNITYUPDATEQ42022"},"OriginalDigest":"OBggtj2uy03WvbPmuWV9X9nKsRQt8I-CbWlqpkqqdyI"},{"content":{"body":"*This post explores definitions and high-level ideas of rollup decentralization. It does not cover deep technical detail about decentralizing rollup implementations.*\n\nWe identify Taiko as a decentralized Ethereum-equivalent ZK-Rollup. Ethereum-equivalent - the moniker of a type-1 ZK-EVM - is a technical design decision that we describe [here](https://mirror.xyz/labs.taiko.eth/w7NSKDeKfJoEy0p89I9feixKfdK-20JgWF9HZzxfeBo).\n\nIn this post, we’d like to talk about the other descriptor in that statement: *decentralized*. We will explore:\n\n* What is the definition of a decentralized rollup?\n\n* How do you decentralize a rollup?\n\n* What are the tradeoffs of a decentralized rollup?\n\n* Taiko’s approach: progressive efficiency\n\n* Decentralized implementation & decentralized governance\n\n* How decentralization is part of Ethereum-equivalence\n\n## What is the definition of a decentralized rollup?\n\nYou may be surprised (or not) to learn that there is some disagreement on the definition of a decentralized rollup. We think we can get pretty close to a widely accepted definition, though:\n\n> A decentralized rollup is one where **any user can be sure that their transaction will be executed**.\n\nWe should take a moment to ask why one may even care whether a rollup is decentralized or not. Given that rollups rely on L1s for security guarantees (mainly Ethereum these days for the leading rollups), aren’t users covered no matter what?\n\nRollups guarantee that as long as the L1 (data availability layer) exists, users can reconstruct the L2 state and **exit the rollup by forcing a transaction on L1.** If the system doesn’t satisfy this constraint, then we would say it does not constitute a rollup; it is a different type of L2 or a sidechain. This should make it clear that choosing a strongly decentralized (always live, censorship-resistant) L1 is crucial. One further nuance is that for a general-purpose rollup, as opposed to an app-specific rollup, users must be able to **force the inclusion of any arbitrary transaction, not just ‘exit’ transactions**.\n\n![](https://images.mirror-media.xyz/publication-images/qgYzOIXPk9sAAJMkrXmz9.png?height=534&width=1522)\n\nOnce established that we are talking about a rollup, we put forth that the distinction that defines a rollup as decentralized or not lies with **how difficult or realistic it is for a user to be able to force their transaction to be included**. For instance, **do they need very powerful computing resources to generate a ZK proof?** Or can they use consumer hardware or rent a cheap server for a short amount of time? Is there some privileged actor that has free reign for an extended period, relegating one’s ability to try to be included to be delayed by 30 days? The less prohibitive, the more decentralized.\n\n![A spectrum exists between these extremes. \"Less decentralized\" is a thing.](https://images.mirror-media.xyz/publication-images/GRZmfwJCCO8SHRT8Q8v4t.png?height=518&width=1652)\n\nIn reality, a typical user would likely wish to avoid running a full rollup node, and in the case of a ZK-Rollup, the prover add-on. They would like to know that the rollup they transact on - or maybe even the rollup they call home - is conducive to having **a wide and diverse set of participants perform the necessary functions**. And that new participants can join the network to perform these functions, permissionlessly - including themselves, if they so wish.\n\nWith the above in mind, let’s finish this section with another definition of a decentralized rollup to help us gain a better understanding:\n\n> A decentralized rollup is one where **multiple parties can participate in each network position** - that is, as proposers, provers, and node runners.\n\nThis leads us to the next section.\n\n## How do you decentralize a rollup?\n\nGiven the above definitions, especially the second one, you may see that we can **decentralize a rollup by ensuring all roles can be performed by multiple parties** - ideally a vast and geographically-diverse set. Those roles are:\n\n* **Proposers**\n\n* **Provers**\n\n* **Node runners**\n\nBefore we review each role, let’s simply review a point touched on in the prior section: rollups, as an L2 solution, decide which L1 they are looking to scale, or more accurately, which L1 they will use for security guarantees. “Security guarantees” here means relying on L1 for consensus and data availability (DA). While this is not something that the rollup itself can tune towards decentralization, **choosing a sufficiently decentralized L1 is a critical decision**, and Taiko chooses Ethereum for the most robust security guarantees.\n\nOn to the roles.\n\n### Proposers\n\nProposers construct rollup blocks from users’ L2 transactions and propose them to L1. Sometimes these are referred to as *Sequencers* in other rollup systems.\n\nProposers decide **which transactions to include in a block and how to order them**. This is a powerful position as it can extract profit from transaction ordering and decide which transactions to exclude, and is thus able to censor certain transactions, applications, or users.\n\nAs we established —> a decentralized rollup should allow users to expect the **inclusion** of all of their valid transactions.\n\n### Provers\n\nProvers generate SNARK proofs asserting the validity of L2 transactions and blocks from the aforementioned proposed blocks.\n\nProvers decide **which proposed blocks to turn into *on-chain verified* blocks**. This position decides when a block can reach its on-chain verified state, but not which txs go in a block or how they are ordered. Until this on-chain verified state, the prover can leave hanging certain transactions that depend on the validity proof, or leave hanging certain *would-be* on-chain verified blocks that are waiting for their parent block to be on-chain verified.\n\nAs we established —> a decentralized rollup should allow users to expect **verification** of all of their valid transactions.\n\n### Node runners\n\nNode runners **execute transactions from on-chain (L1) data** to stay in sync with the rollup state.\n\nProposers and provers need to run full rollup nodes to fulfill their respective roles. Other actors would also want to run nodes, such as those offering services like a block explorer, infrastructure providers, and users who want to stay in sync with the chain state for other reasons.\n\nAs we established —> a decentralized rollup should allow users to expect **the execution** of all of their valid transactions.\n\n*Note: while decentralizing proposers/provers is an explicit rollup protocol decision (e.g. the smart contracts may be configured to only accept blocks or proofs from allowlisted addresses), running a node is mostly a resource consideration that depends on state growth, hardware requirements, etc., and is not an outright protocol decision. Catering to reasonable state growth is critical, but is not discussed in this post.*\n\n## What are the tradeoffs of a decentralized rollup?\n\nMoving along a spectrum of centralization to decentralization exposes a tradeoff space.\n\nFor this section, the pros and cons apply to both proposers and provers (which we collectively term *operators*); we will leave out node runners, as mentioned, but keep in mind that running a rollup node is a requirement for both roles.\n\nIn the context of rollup proposers/provers, we view the following:\n\n![](https://images.mirror-media.xyz/publication-images/H4fWx08a3pCgi9aoBplC1.jpg?height=1080&width=1470)\n\n## Taiko’s approach: progressive efficiency\n\nThe current approach chosen by most in-production general-purpose rollups has been one of centralization at first, with a commitment to progressive decentralization over time. This has made some sense, as there are several moving pieces, assumptions to test, and it is early. Having a centralized proposer and prover (aka sequencer and validator in broader terms) has made it more simple to ensure the proper and efficient functioning of the rollup. We can see this popular approach in the below table.\n\n![Source: L2beat.com. Displays different risks of rollups. For the topics we are discussing, a rollup with decentralized proposers and provers would have \"Propose Blocks\" in the Sequencer and Validator Failure columns (and it would be highly accessible for users to operate such). As you see, none of the above currently satisfies both. ](https://images.mirror-media.xyz/publication-images/SqkUnUfUBUPWV-eOCjHkG.png?height=808&width=2264)\n\nTaiko, on the other hand, aims to go live with a **fully decentralized (and permissionless) proposer and prover set**. The protocol will not enshrine or allowlist any parties; anyone will be able to perform those duties. Further, Taiko plans to have a minimal protocol-defined coordination scheme for proposers/provers. The current plan is for it to be leaderless.\n\nAll rollups will choose the sweet spot that suits the needs of their users. That spot will be different across rollups, and the *path* to reach the same spot may also be different. You can start centralized and loosen control, or you can start decentralized and implement tight coordination rules (or perhaps even assign control). It is certainly possible that some of the decentralization disadvantages are impediments to a suitably performing network, at which point Taiko can implement measures such as leader election schemes to avoid redundant work.\n\n> In this sense, Taiko’s approach may be considered **progressive efficiency**, as opposed to progressive decentralization; moving from the completely decentralized and unstructured extreme, and more towards the middle, if needed.\n\nThis is not to say that Taiko will be completely “[training-wheel-free](https://ethereum-magicians.org/t/proposed-milestones-for-rollups-taking-off-training-wheels/11571)” from the beginning. Certain measures like smart contract upgradeability will remain in place until things are battle-tested. This is guided by a security-minded approach: without proxy-based upgradability, users’ assets can face significant bug risks. Controlled upgradability is one of the levers that will be handed over to the DAO at some point.\n\n## Decentralized implementation and decentralized governance \n\nVitalik recently [wrote](https://vitalik.ca/general/2022/12/05/excited.html) that *“decentralized governance structure protects against attackers on the inside, and a decentralized implementation protects against powerful attackers on the outside.”* This was said in the context of DAOs - that is, both the governance structure *and* implementation pertained to DAOs. Specifically, it was said for one aim of DAO decentralization: robustness.\n\nWe think it is quite helpful to use this framing for rollups at large and split “governance structure” into meaning a rollup’s DAO, full stop (taking for granted the governance implementation is smart contract based), and “implementation” into meaning the rollup’s architecture itself.\n\n![Source: https://vitalik.ca/general/2022/12/05/excited.html](https://images.mirror-media.xyz/publication-images/e0I7SfTDP4eUIsrZ0hmtm.png?height=520&width=2580)\n\nIn this light, we have so far discussed how a rollup can defend itself against outside threats (censorship, liveness failures) with a decentralized implementation. **We mustn’t neglect how a rollup can defend itself against internal threats** - against the organization and community charged with initially building and maintaining it. The tool at a rollup’s disposal here is governance, or simplified, its DAO.\n\nWhen it comes to governance, Taiko adopts an approach that is similar to other rollups, and similar to most protocols on Ethereum in general, from DeFi to infrastructure. This approach is indeed one of progressive decentralization: control over the protocol will gradually be relinquished to the community, specifically to the Taiko DAO. It is too early to describe the details of the DAO and which governance mechanisms we would propose it adopts, but this will be the subject of future posts.\n\nAs a final thought on this topic: we view that **implementation offers a point-in-time analysis of a rollup’s properties, while governance can describe how the implementation may change over time**, and which parties can make those decisions.\n\n## How decentralization is part of Ethereum-equivalence\n\nOn its quest for pure Ethereum-equivalence, Taiko highly values its prioritization of decentralization. It would seem odd to have equivalence as a goal encompass the EVM, hash functions, state and tx trees, etc., without also connoting equivalence in network composition.\n\nEmulating Ethereum for Taiko means everything aligns towards Ethereum: the ZK-EVM, other Ethereum base layer architecture, philosophical considerations, community, and \\~vibes\\~. This extends to network decentralization and the main properties it provides for developers and their users: censorship-resistance and liveness.\n\nThanks for reading.\n\n### Join us\n\nExplore open positions on our [job board](https://www.notion.so/Taiko-Jobs-828fd7232d2c4150a11e10c8baa910a2).\n\n### Follow us\n\nTo stay updated on the latest from Taiko:\n\n* Website: [https://taiko.xyz](https://taiko.xyz/)\n\n* Discord: \n\n* GitHub: \n\n* Reddit: \n\n* Twitter: \n\n### Contribute\n\nContribute to Taiko and earn a GitPOAP! You will also be featured as a contributor on our README. Get started with the [contributing guide](https://github.com/taikoxyz/taiko-mono/blob/main/CONTRIBUTING.md).","timestamp":"1671562994","title":"Rollup Decentralization"},"digest":"uCDRVgVVRxRVbzKYgiY6_UgMPNV-uiPejcBasBemZ_8","authorship":{"contributor":"0x381636D0E4eD0fa6aCF07D8fd821909Fb63c0d10","signingKey":"{\"crv\":\"P-256\",\"ext\":true,\"key_ops\":[\"verify\"],\"kty\":\"EC\",\"x\":\"KLghZbUEjaY2lt26UoPwbZTQsrwW80OIsi64Hm-lLGc\",\"y\":\"ETAVyVNAc24z-k4CIt7wHxkxJKYuoOmsfuJrDnFZYsM\"}","signature":"0xd4bba22b4dbfb6403519d81ce7391c8aafcb801cb94bb4112f0c05fac2836b152a43c3cc7c457a2107fd5a118aad220d0ce620a6174bcae20dde6bd896a52db71b","signingKeySignature":"cqZ51jwr4Gpx3Q_hovb_OD6gWtqlK4gl86ZY3p6F1Hu_Tn0B__oF29BSL1OnyI_3TxbjHImVhRu1_Pgdt6Y4Yw","signingKeyMessage":"I authorize publishing on mirror.xyz from this device using:\n{\"crv\":\"P-256\",\"ext\":true,\"key_ops\":[\"verify\"],\"kty\":\"EC\",\"x\":\"KLghZbUEjaY2lt26UoPwbZTQsrwW80OIsi64Hm-lLGc\",\"y\":\"ETAVyVNAc24z-k4CIt7wHxkxJKYuoOmsfuJrDnFZYsM\"}","algorithm":{"name":"ECDSA","hash":"SHA-256"}},"version":"04-25-2022","wnft":{"chainId":10,"description":"Decentralized rollups ensure any user can have their transaction included, providing censorship-resistance and liveness guarantees.","fee":250,"fundingRecipient":"0x381636D0E4eD0fa6aCF07D8fd821909Fb63c0d10","imageURI":"QmTSTqMcWZUY4nMNA7FDYeZfBkC2MNWFZAH36729xZr1mP","mediaAssetId":321350,"name":"Rollup Decentralization","nonce":5609135,"owner":"0x381636D0E4eD0fa6aCF07D8fd821909Fb63c0d10","price":0,"proxyAddress":"0x8e4AF7682d1fa3C32CFA033Ae861e7c1533A83d0","renderer":"0x0000000000000000000000000000000000000000","supply":500,"symbol":"ROLLUPDECENTRALIZATION"},"OriginalDigest":"sxR3iKyD-GvTuyI9moCg4_ggDI4E4CqnvhdwRq5yL0A"}] \ No newline at end of file From 13a53706b0c55f33e6ae058b05bbd3ad822f1632 Mon Sep 17 00:00:00 2001 From: Luuk Date: Sun, 26 Feb 2023 21:42:12 +0100 Subject: [PATCH 15/16] refactor --- packages/website/pages/api/getPosts.js | 103 ++++++++++++------------- 1 file changed, 51 insertions(+), 52 deletions(-) diff --git a/packages/website/pages/api/getPosts.js b/packages/website/pages/api/getPosts.js index 08af56cfd14..67607acbb1b 100644 --- a/packages/website/pages/api/getPosts.js +++ b/packages/website/pages/api/getPosts.js @@ -6,72 +6,71 @@ const arweave = Arweave.init({ protocol: "https", }); -const posts = []; -const hoursBetweenBlogPostFetches = 1 +let posts = [] +const hoursBetweenBlogPostFetches = 1; const getTransactionIds = async () => { - await fetch("https://arweave.net/graphql", { + const response = await fetch("https://arweave.net/graphql", { method: "POST", headers: { "Content-Type": "application/json", }, body: JSON.stringify({ query: ` - query { - transactions( - first: 100 - sort: HEIGHT_DESC - tags: [ - { - name: "Contributor" - values: ["0x5b796c4B197B6DfD413f177059C27963EB80af0F","0x2b1F13149C7F89622BBfB46Ae1e3ECc573Bb9331","0x381636D0E4eD0fa6aCF07D8fd821909Fb63c0d10"] - }, - { - name: "App-Name" - values: "MirrorXYZ" - } - ] - ) { - edges { - node { - id - tags { - name - value - } - } - } + query { + transactions( + first: 100 + sort: HEIGHT_DESC + tags: [ + { + name: "Contributor" + values: ["0x5b796c4B197B6DfD413f177059C27963EB80af0F","0x2b1F13149C7F89622BBfB46Ae1e3ECc573Bb9331","0x381636D0E4eD0fa6aCF07D8fd821909Fb63c0d10"] + }, + { + name: "App-Name" + values: "MirrorXYZ" + } + ] + ) { + edges { + node { + id + tags { + name + value } } - `, + } + } + } + `, }), - }) - .then((res) => res.json()) - .then((response) => { - getPosts(response); - }) - .catch(); + }); + + const responseJSON = await response.json(); + posts = await getPosts(responseJSON); }; async function getPosts(response) { - posts.length = 0; - Promise.all( - response.data.transactions.edges.map((edge) => { - const transactionId = edge.node.id; - arweave.transactions - .getData(`${transactionId}`, { decode: true, string: true }) - .then((response) => JSON.parse(response)) - .then((data) => { - // Check if the posts have the required keys - if (data.hasOwnProperty("wnft")) { - // add the original digest - data["OriginalDigest"] = edge.node.tags[4].value; - posts.push(data); - } - }) - .catch(); - }) - ); + const newPosts = []; + const promises = response.data.transactions.edges.map(async (edge) => { + const transactionId = edge.node.id; + + const response = await arweave.transactions.getData(`${transactionId}`, { + decode: true, + string: true, + }); + const data = JSON.parse(response); + // Check if the posts have the required keys + if (data.hasOwnProperty("wnft")) { + // add the original digest + data["OriginalDigest"] = edge.node.tags[4].value; + newPosts.push(data); + } + }); + + await Promise.all(promises); + return newPosts; } getTransactionIds(); From a6ec4dd0dfcb22c0062e174e32b2af6cf222638b Mon Sep 17 00:00:00 2001 From: Luuk Date: Fri, 3 Mar 2023 16:34:27 +0100 Subject: [PATCH 16/16] fix sometimes not showing --- packages/website/components/BlogSection.tsx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/packages/website/components/BlogSection.tsx b/packages/website/components/BlogSection.tsx index 0846c9099b8..19217d096a2 100644 --- a/packages/website/components/BlogSection.tsx +++ b/packages/website/components/BlogSection.tsx @@ -76,7 +76,7 @@ function getDateTime(timestamp: string): string { export default function BlogSection(): JSX.Element { const [posts, setPosts] = useState([]); - useEffect(() => { + if (posts.length < 3) { fetch("/api/getPosts") .then((response) => response.json()) .then((json) => { @@ -84,7 +84,7 @@ export default function BlogSection(): JSX.Element { json = json.slice(0, 3); setPosts(json); }); - },[]); + } return (