📜 [專欄新文章] 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.
👏 歡迎轉載分享鼓掌
同時也有10000部Youtube影片,追蹤數超過2,910的網紅コバにゃんチャンネル,也在其Youtube影片中提到,...
javascript sender 在 Kewang 的資訊進化論 Facebook 的最讚貼文
上星期大家都有來聽小編在 COSCUP 分享的「模糊也是一種美 - 從 BlurHash 探討前後端上傳圖片架構」嗎?這個技術已經有實作在 Funliday-旅遊規劃 的 Web 跟 Android 囉。這個議題結束後,有朋友問了一些問題,這裡順便來統整回答一下:
1. client side upload 方式從 server 產出的 signed URL 是個什麼樣的東西?
signed URL 是為了讓沒有 access key 及 secret key 的 sender 也能在有權限管理的保護下做 S3 的檔案處理,而 Funliday 在這裡的實作是不用原檔名做 key,改用 UUID 產生避免檔名衝突。
2. client BlurHash decode 的效率如何?
在做 BlurHash decode 的時候因為用到的是 CPU 運算,而且 JavaScript 又是 single thread 的關係,所以在 decode 同時移動畫面的話,可能會造成 CPU 不夠力的 client 會有極短暫的延遲時間。這時候可以考慮把 decode 丟到 web worker 處理,避免卡到 UI thread 的順暢度。用 Android 的術語來說就是開 AsyncTask 啦!
3. 你們後來是使用哪種方式做上傳呢?
原先是使用 server side (2) 的方式,但在處理 MQ 上傳後的 notify 花了不少時間,而且上傳到 S3 也沒這麼快,所以後來改用 client side 的方式做上傳功能,運作上也比原先的方式順暢。
4. 為什麼不用 medium 的方式處理 blur?
因為 medium 檔案比 BlurHash 的字串大很多,而且要多發一次 request,成本比 BlurHash 高出不少,所以我們認為用 BlurHash 會是比較好的。
---
當然也是要感謝 gslin 大大,他在 4/26 (日) 簡單介紹了 BlurHash。小編下午看到這篇文章,馬上丟去 slack 問我們的設計師大大,看她覺得這效果如何?她過沒多久回覺得不錯,小編就在星期日的下午開始處理 server side 的實作。隔天星期一有了初步的成果,然後給我們的安卓五星上將看,星期二就完成 Android 實作並上線了!
也是因為 CDN 那塊後來把原先的 lambda 改用自己寫的 server 處理,所以實作 BlurHash 才能這麼快。lambda 這塊也是血淚史,下略 10000 字,之後有機會再跟大家分享。
---
歡迎大家對這塊有興趣的也來交流一下喔!
#blurhash #coscup