📜 [專欄新文章] Scaling Ethereum 參賽心得
✍️ Johnson
📥 歡迎投稿： https://medium.com/taipei-ethereum-meetup #徵技術分享文 #使用心得 #教學文 #medium
Scaling Ethereum 是一場由 ETHGlobal 所舉辦的線上黑客松，也是我第一次參加與以太坊有關的黑客松活動，這篇文章就來分享一人參賽的過程與心得。
源起
一開始是在 telegram 群組中得知這場比賽的消息，因緣際會之下剛好有人想組隊參賽，於是就在報名截止的前一天一起跟著報名了。
報名的方式除了填一些基本資料外，最特別的是還要 stack 以太幣，也就是要傳送 0.01 顆以太幣給主辦方，規則是必須在比賽的最後，有提交作品的人才能贖回 0.01 顆以太幣，之後看到 meme 頻道有人留言：
When your project is incomplete but you submit to get back stake.
一方面，這確實也會激勵你好好把比賽完成，就算沒做完也要有些成果上去，這也是主辦方秉持的精神，他們認為大家來黑客松相互學習成長，競賽獎金則是其次。
獎金
比賽方式是由 25 個左右的贊助者（sponsor）分別提供獎金，每個 sponsor 都有錄製一段影片，說明怎麼獲得他們的獎金，大部分會要你使用他們開發的工具，或者必須跟 sponsor 在做的研究有關，去實作出創新的作品。可參考：Prizes — Scaling Ethereum
你的專案可以選擇要投入哪個 sponsor 的獎金，一個專案可以投入多個 sponsor 底下，這樣獲獎機會也會比較高。
我選擇的 sponsor 是 zkSync，他們的說明如下：
zkSync is a user-centric zkRollup developed by Matter Labs. It uses zero-knowledge proofs to keep data availability on mainnet to achieve exponentially lower transaction costs. You may have seen us powering projects such as payments and Gitcoin Grants. We are currently rapidly developing zkSync 2.0, which will feature EVM-compatibility in testnet May 2021, soon followed by zkPorter, our new exponential scalability solution.
PrizeszkSync will be awarding their Prizes as follows:
- 1 winner — 4,000 USDC
- 2 winners — 2,000 USDC
- 4 winners — 500 USDC
We encourage builders to utilize zkSync SDK’s, implemented in JavaScript/Typescript and Rust. Prizes will be awarded to projects that make it simpler and easier for non-technical users to use zkSync, other ideas include integrations of current tools such as in Gitcoin Grants and tools for easy mass payments and multi-sigs.
社群互動
這個 hackathon 很棒的地方是他把使用者體驗做的很好。每個人都會有自己的 dashboard 顯示目前專案的進度和一些訊息。
Check-In #1 和 Check-In #2 的階段會要你提供專案的構想，你隨時都可以修改。主辦方會看你提交的資訊，幫助你找到適合的 sponsor，或是給你一些建議，就算是一人參賽也能感受到回饋。
整個賽程期間，社群都是使用 discord 在互動，discord 裡頭有很多頻道，像是基本的大會報告的頻道，或是一些不重要的迷因、閒聊頻道都有。
每個 sponsor 也都有自己的頻道，我就會在 sponsor-zksync 的頻道詢問技術的問題，例如我想問問 zkSync 一些關於專案構想的意見：
Hi there, I want to build a gas fee relayer which make my ERC-20 token transfer without transaction fee, to be more precise, delegating gas payment by another party. I think this is done by GSN https://opengsn.org/ , but maybe it could built on L2 with zkSync? I’m not sure, could somebody give me some advice about this topic?
zkSync 團隊的人回應我：
This is an amazing idea! This can totally be built, as we support batching transactions which can be used for all kinds of creative things such as paying for transaction fees in an erc-20 token. Your idea seems like a combination of that and the gitcoin grants integration. To get started, I suggest you watch the short 10 minute presentation I made on using the SDK and batching. Looking forward to your project!!
在 Check-In #2 的時候，我提交新版的專案構想，有一個欄位是問：「目前專案遇到什麼阻礙？」我的問題應該是被主辦方貼給 zkSync 的團隊，於是 zkSync 的團隊成員就用 discord 私訊我，貼了一些程式碼教我怎麼使用他們的 Javascript SDK，這突如其來的救援也幫了大忙。
除此之外，主辦方每個禮拜都會寄 email 通知一些重要的活動，賽程期間舉辦了四個 Summits 研討會，邀請世界各地有名的以太坊開發者分享議題，主辦方還有一個自己的 TV 網頁，直播所有的線上活動。這些活動都有錄影，可以在 youtube 看到過去所有的演講內容：https://www.youtube.com/c/ETHGlobal/videos
因為我的作品是使用 zkSync 的 Javascript SDK 製作的，好像也只能投稿 zkSync 作為獎金的 sponsor，不過主辦方在最後一個禮拜，也寄 email 告訴我說可以多投稿不同的 sponsors 看看，他依據我的專案構想給我一些適合的 sponsors 作為參考。
不過最後我還是只投稿了 zkSync，有點懶著再看其他 sponsors 的文件，也覺得其他 sponsors 的題目需要花比較大的功夫才能完成，一個人能力有限，就做點簡單的東西就好。
關於我的專案 — Gas Relay Service
在以太坊的世界，每一筆交易都需要額外付一筆交易費，也就是以太坊的 gas fee。
我的專案是讓「收款人」能夠幫「付款人」支付以太坊的手續費。
在黑客松之前，我就想研究「第三方支付手續費」的議題，因此我大部分時間其實都在研究一般的 meta-transactions 是怎麼實作的，有興趣的人可以看看 simple meta-transactions 的原始碼：https://github.com/chnejohnson/simple-meta-transaction
之後我才開始玩 zkSync 的 SDK，並研究怎麼在 Layer 2 實現第三方支付手續費的問題，以下就附上作品連結以及簡單的專案介紹給有興趣的人參考：https://showcase.ethglobal.co/scaling/gas-relay-service-on-zksync
The target is that token sender can choose to find another account to pay for fee. The another account can be (1) the token receiver’s account, (2) sender’s another account, (3) third party’s account.
In this project, I finished the demo, which is the (1) above, that receiver pay gas fee for the sender.
有趣的是，我在研究 meta-transactions 時學到很多智能合約的寫法，結果在最後專案上都沒用到（沒寫到合約的程式），zkSync Javascript SDK 其實很簡單，他們的文件寫得很清楚。最後 Demo 還是用 zkSync 團隊的成品修改來的…XD。
所幸在沒有懂太多技術的前提下完成了這場黑客松的專案，成功贖回了 0.01 顆以太幣。
評審與決選
整個賽程來到最後一個禮拜，主辦方安排兩天的時間進行 Judges，使用 zoom 進行線上研討會，一個人基本上是 7 分鐘，前 4 分鐘播放 Demo 簡報，後三分鐘會有評審問問題。
第一個問題是說：「Demo 中你是使用 zkSync 的錢包網頁去操作，那實際上你做得部分是什麼？」
我就回答我在他們的網頁上加了一顆按鈕，使用他們的 SDK 做出 gas relay 的功能，還有一個後端的 server 去作 relay。
第二個問題大概是問：「什麼樣的情境下會需要由 receiver 幫 sender 支付 gas fee？」
我的回答是，在一般超商購物的情境，消費者通常只支付商品的價格，不會支付額外的交易費，我認為以太坊的手續費應該屬於軟體的營運成本，由賣方支付比較適合。那如果賣方希望手續費的成本是由消費者承擔，可以直接調高商品的價格。
當然，我英文講得零零落落，希望評審有聽懂就是了…
最後一場直播就是 Finale 決選，主辦方選出十二個隊伍，公開再 Demo 一次，以及提供線上觀眾詢問問題，至此整個賽程就差不多進入尾聲。
決選後的不久，主辦方就公布了這次有獲得獎金的隊伍，幸運拿到了 zkSync 頒發的小獎～
zkSync — Matter Labs
- Zeneth — 2000 USDC
- ZeroSwap — 1500 USDC
- Kangaroo — 500 USDC
- Gas Relay Service — 500 USDC
後記
這次的參賽隊伍中，Zeneth 跟我的主題非常相似：
Zeneth — Use Flashbots to enable arbitrary meta-transactions so EOAs can enter L2s without ETH
另一個我覺得有趣的專案是 Alexandria：
Alexandria — A dApp using STARKs to verify aspects of your identity without revealing more than you should
沒想到主辦方 ETHGlobal 下個月又要再舉辦一場黑客松，有興趣的人可以看看：https://defi.ethglobal.co/ ，這次的主題是 De-Fi。
最後，只要有到 ETHGlobal 的 TV 網頁參加 Summit 研討會的直播，就能夠獲得 POAP 勳章，它就是一個酷東西～😋
POAP: Proof of Attendance Protocol
Scaling Ethereum 參賽心得 was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.
👏 歡迎轉載分享鼓掌
rust c++ 比較 在 Re: [問題] 請問關於Rust 跟C 的速度比較- 看板C_and_CPP 的推薦與評價
※ 引述《os653 ()》之銘言：
: 最近在練習 Rust，聽說執行速度可以跟 C 相當
: 但看了下面網頁的執行速度比較，似乎 Rust 還是略輸一截
: https://benchmarksgame.alioth.debian.org/u64q/rust.html
: 請問這是為什麼？
: 在我的粗略理解上，Rust 的很多東西都是在編譯期就處理掉了
: 而且因為變數的定義較為嚴格，還有可能編出較短的機械碼
: 那理論上應該會比 C 快才對呀？
Hi, 在開始說明前，建議你可以先看一下 benchmarks game 針對效能比較的說明
https://benchmarksgame.alioth.debian.org/dont-jump-to-conclusions.html
他們開宗明義就講：每個程式語言設計時要達成的目標不一樣
單純地實作相同演算法並比較它們的效能，其實是LP比雞腿
Rust 在設計上的首要目標是 memory safe 與 thread safe
並且在提供高階抽象化的同時，儘可能維持良好的執行效能
而 C 的目標是取代當時 (1973) 雖然效能好但不易跨平台的組合語言
因此它允許 undefined behavior，而且提供許多低階的操作
確實 Rust 在 compile time 就做了許多 safety check 來提高 runtime 效率
但有些與 memory safety 相關的檢查確實很難在 compile time 實現
而 C compiler 根本就不管 memory safety 的
這種時候，Rust 的執行效率確實會比 C 還要慢
最簡單最常見的例子就是陣列存取
像這樣的程式碼：
array[i] = x;
Rust 的效率會明顯低於 C
因為 compiler 無法在 compile time 確認 i 是否落在 array 的長度限制內
為了不引發 undefined behavior，它必需在 runtime 幫你做邊界檢查。
事實上，所有 memory safe 的語言，在這樣的陣列存取時都會做邊界檢查。
大家會說 Rust 的效能很好，多半是與其它 memory safe 的語言比較
比如說 C# / Java / Go，而不是和 C 比較。
* * *
所以 Rust 一定比 C 還要慢嗎？那也不一定。
你可以看看 C 與 C++ 在 benchmarks game 上面的比較，
幾乎所有的測試中 C 都比 C++ 還要快。
但是，如果你比較 C++ 的 std::sort 與 C 的 qsort
那麼 C++ 肯定是壓倒性的勝利
當然，如果要比排序，你還是可以用 C 手刻一個與 C++ sort 相同的版本
但，當你使用某個語言寫程式，而標準函式庫提供了 qsort
你還會手刻一個自己的 sort 出來嗎？
「使用某語言」在一定程度上，包含了「使用某語言的library」
這也算是 benchmarks game 的一項規則
上面的測試程式碼會儘可能使用該語言提供的函式庫
以符合使用該語言寫程式的普遍情況
因此，benchmarks game 上面某個語言的效能，應該要被理解為它的「平均表現」
而不是該語言的「極限」
以 C 與 Rust 的比較中，其中 C 表現得比較好的測試像是 mandelbrot 或 n-body
C 都使用了 SIMD 指令以提昇效率
但是目前 Rust 的 SIMD 尚未成為標準功能，因此範例碼中也未使用 SIMD 加速
這是否表示 Rust 不能用 SIMD 呢？並不是
你真的想做，還是可以用 unsafe block 與 inline asm 做到
但這不會是 Rust programming 的常態
畢竟如果你那麼在意效能，覺得效能比 memory safe 或易讀易寫更重要
那 C 還是比較適合的選擇
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 125.227.5.133
※ 文章網址: https://www.ptt.cc/bbs/C_and_CPP/M.1502645537.A.264.html
... <看更多>