Regina's Digital Garden

Account

Mon, 22 Jun 2026 00:00:00 +0000

Media Kit

Mon, 22 Jun 2026 00:00:00 +0000

Members-only: My ZK research notes

Mon, 22 Jun 2026 00:00:00 +0000

A members-only deep dive — subscribe or unlock to read the full notes.

媒體資料包

Mon, 22 Jun 2026 00:00:00 +0000

帳戶

Mon, 22 Jun 2026 00:00:00 +0000

How I Use AI Tools as a Web3 Developer

Fri, 08 Nov 2024 00:00:00 +0000

It’s been about a year since I started integrating AI tools seriously into my development workflow. I resisted for longer than I should have — partly scepticism, partly the classic developer ego thing of “I should be able to figure this out myself”. Eventually I caved, and I have thoughts.

What Actually Helps

Boilerplate and scaffolding. Asking an AI to generate a basic ERC-721 contract or a standard API handler is genuinely useful. Not because I can’t write it, but because starting from a skeleton and modifying it is faster than starting from a blank file every time. The generated code is usually sensible enough to be a good starting point.

Explaining unfamiliar code. I work with a fair bit of code I didn’t write — open source contracts, legacy services, other people’s ABIs. Pasting a function and asking “what does this do and what should I watch out for?” saves a lot of time jumping between documentation tabs.

Writing tests. I dislike writing tests for obvious-behaviour functions. AI is surprisingly good at generating unit test cases, including edge cases I might have glossed over. I still review everything but the coverage improves noticeably.

What Doesn’t Work Well

Anything bleeding-edge or niche. If you’re working with a protocol that launched six months ago, or a new L2 with limited public documentation, the AI will confidently give you outdated or hallucinated information. This is dangerous in Web3 where a wrong address or incorrect contract ABI loses real money. I always cross-reference with official docs for anything chain-specific.

Auditing smart contracts. I have seen developers paste their Solidity into an AI and treat the response as a security review. Please don’t do this. AI can catch obvious patterns but it misses subtle re-entrancy issues, business logic bugs, and protocol-specific edge cases. Use proper auditing tools and if it’s going to hold real value — get an actual audit.

Architecture decisions. Great for tactics, not great for strategy. Asking “how do I implement this function” works. Asking “how should I structure this entire system” tends to produce generic advice that doesn’t account for your specific constraints.

My Current Stack

I mostly use Claude for code explanations and Go/Solidity generation, and GitHub Copilot for autocomplete while I’m typing. They serve different purposes and work well together. I turn Copilot off sometimes when I’m in “deep thinking” mode because the autocomplete starts to feel like it’s steering my thoughts rather than following them.

The Bigger Picture

I think the honest answer is: AI tools make the boring parts of development faster, which frees up time for the parts that actually require thinking. For Web3 specifically, the “require thinking” parts are non-trivial — the security surface is large and the cost of mistakes is high. So my approach is to use AI for speed on the low-risk stuff, and stay cautious on anything that touches user funds or sensitive logic.

It’s a tool. A pretty useful one. But it’s not a replacement for understanding what you’re building.

身為 Web3 開發者，我怎麼使用 AI 工具

Fri, 08 Nov 2024 00:00:00 +0000

距離我開始認真把 AI 工具融入開發工作流程，大概已經一年了。我抵抗了比應該更長的時間——一部分是懷疑，一部分是那種「這個我自己應該搞得定」的開發者自尊心。最後還是投降了，然後有些想法想記下來。

真的有用的地方

樣板程式碼與腳手架。 請 AI 生成一個基本的 ERC-721 合約，或標準的 API handler，真的很有用。不是因為我不會寫，而是從一個骨架開始修改，比每次面對空白檔案快多了。生成的程式碼通常夠好，足以作為起點。

解釋不熟悉的程式碼。 我工作中會接觸到很多不是我寫的程式碼——開源合約、舊系統、別人的 ABI。把一個函式貼進去問「這在做什麼，有什麼要注意的？」，省了很多在文件分頁之間跳來跳去的時間。

寫測試。 我不喜歡為那些行為很明顯的函式寫測試。AI 很擅長生成單元測試案例，包括一些我可能會略過的邊緣情況。我還是會全部看過，但覆蓋率明顯提高了。

效果不好的地方

任何很新或很小眾的東西。 如果你在用六個月前才發布的協議，或文件很少的新 L2，AI 會很有自信地給你過時或是幻覺出來的資訊。在 Web3 裡這很危險——一個錯誤的地址或合約 ABI 會導致真實的資金損失。任何跟鏈相關的東西，我都一定會對照官方文件確認。

智能合約審計。 我看過有開發者把 Solidity 貼給 AI，然後把回應當成安全審查的結果。請不要這樣做。AI 可以抓到明顯的模式，但它會漏掉微妙的重入攻擊（re-entrancy）漏洞、商業邏輯錯誤，以及特定協議的邊緣情況。用正規的審計工具，如果要放真實資金，就找真正的審計。

架構決策。 戰術問題問得很好，策略問題問得不太行。「這個函式怎麼實作」有用，「這整個系統應該怎麼設計」得到的往往是通用建議，沒辦法考慮你的具體限制。

我現在的工具組合

我主要用 Claude 來解釋程式碼和生成 Go/Solidity，用 GitHub Copilot 在打字的時候自動補全。它們服務不同的目的，搭配起來效果不錯。Copilot 我有時候會關掉，在「深度思考」模式的時候——因為自動補全開始感覺像是在引導我的思路，而不是跟著我走。

更大的圖景

說實在的：AI 工具讓開發裡那些無聊的部分變快了，這釋放出時間來處理真正需要思考的部分。對 Web3 來說，「需要思考的部分」並不簡單——攻擊面很大，犯錯的代價很高。所以我的做法是，在低風險的事情上用 AI 加速，在任何碰到使用者資金或敏感邏輯的地方保持謹慎。

這是個工具，一個相當有用的工具。但它不能取代對你在建構什麼的理解。

Shop

Mon, 01 Jan 2024 00:00:00 +0000

商店

Mon, 01 Jan 2024 00:00:00 +0000

Why I Reach for Go When Building Web3 Backends

Tue, 02 May 2023 00:00:00 +0000

I have been writing Go professionally for over a year now, mainly for the backend of Web3 products. Before that I was mostly JavaScript and Python. I want to write down why Go has become my default choice for anything backend in the Web3 space, because I wish someone had told me this earlier.

The Concurrency Thing is Real

When you’re building something that listens to blockchain events — indexing transactions, watching contract events, syncing state — you need concurrency that doesn’t make you want to cry. Go’s goroutines are genuinely easy to use compared to JavaScript’s async/await chains or Python’s asyncio.

A simple example: listening to multiple smart contract events simultaneously and writing them to a database. In Go this is a handful of goroutines and a few channels. Clean and readable.

go-ethereum is Excellent

The go-ethereum library (geth) is the reference Ethereum client and it’s written in Go. Using it from Go feels native in a way that doesn’t quite translate to other languages. You can subscribe to events, call contract functions, sign and send transactions — all with proper types, none of the any and casting chaos I used to deal with in TypeScript.

client, err := ethclient.Dial("wss://mainnet.infura.io/ws/v3/YOUR_KEY")
if err != nil {
 log.Fatal(err)
}

query := ethereum.FilterQuery{
 Addresses: []common.Address{contractAddress},
}

logs := make(chan types.Log)
sub, err := client.SubscribeFilterLogs(context.Background(), query, logs)

That’s it. No callback hell. Errors are explicit. I know exactly what’s happening.

Performance Matters at Scale

On a busy chain like Polygon or during a token launch, your backend might be processing hundreds of events per second. Go’s performance here is just in a different league from Python. I noticed this the first time we had a high-traffic period at work — the Go service barely moved on CPU, while the old Python service we had experimented with earlier would have been struggling.

The Learning Curve is Honest

Go is opinionated and the error handling is verbose. Writing if err != nil fifty times per file feels tedious at first. But this explicitness saved me multiple times when I was new to the codebase — every failure path is explicit, not hidden behind an exception that might bubble up in a weird way.

If you are coming from JavaScript, the static typing will also feel restrictive initially. Give it two weeks. You’ll miss it in every other language after that.

What I’m Building With It Now

Currently using Go to build a token-gating API — it checks NFT ownership and issues signed session tokens for gated content access. Go’s standard library handles the crypto primitives really well, and the binary compiles to a single self-contained executable which makes deployment painless.

If you are building anything in the Web3 backend space and haven’t tried Go, I’d really recommend it. The ecosystem is mature and the language is genuinely a pleasure once it clicks.

為什麼我做 Web3 後端都選 Go？

Tue, 02 May 2023 00:00:00 +0000

我現在用 Go 寫後端已經超過一年了，主要是為 Web3 產品開發後端服務。在這之前，我大部分時候都在用 JavaScript 和 Python。想把這些心得寫下來，說說 Go 是怎麼成為我 Web3 後端開發的預設選擇——因為我希望有人早點跟我說這件事。

並發（Concurrency）真的很重要

當你在做監聽區塊鏈事件的東西——索引交易、監聽合約事件、同步狀態——你需要一種不會讓你抓狂的並發機制。Go 的 goroutine 跟 JavaScript 的 async/await 巢狀結構，或 Python 的 asyncio 相比，真的容易用多了。

一個簡單的例子：同時監聽多個智能合約事件並寫入資料庫。在 Go 裡，幾個 goroutine 加上幾個 channel 就搞定了，程式碼乾淨又好讀。

go-ethereum 非常好用

go-ethereum 函式庫（也就是 geth）是以太坊的參考用戶端，用 Go 撰寫。從 Go 直接呼叫它，有一種原生的感覺，是其他語言比不上的。你可以訂閱事件、呼叫合約函式、簽名並發送交易——全部都有完整的型別，不像 TypeScript 那樣到處是 any 和型別轉換的混亂。

client, err := ethclient.Dial("wss://mainnet.infura.io/ws/v3/YOUR_KEY")
if err != nil {
 log.Fatal(err)
}

query := ethereum.FilterQuery{
 Addresses: []common.Address{contractAddress},
}

logs := make(chan types.Log)
sub, err := client.SubscribeFilterLogs(context.Background(), query, logs)

就這樣。沒有回呼地獄，錯誤處理一目了然，我知道每一步都在幹嘛。

效能在大規模時很關鍵

在 Polygon 這種繁忙的鏈上，或是代幣發行期間，後端每秒可能要處理幾百個事件。Go 在這方面的效能跟 Python 根本不是同個量級。我在工作中第一次遇到流量高峰的時候就感受到了——Go 服務的 CPU 幾乎沒有波動，而我們之前實驗性用的 Python 服務在那種情況下早就掙扎了。

學習曲線是誠實的

Go 有自己的風格，錯誤處理很囉嗦。每個函式都要寫一遍 if err != nil 一開始感覺很煩。但這種明確性讓我好幾次在讀別人的程式碼時救了我——每個失敗路徑都清清楚楚，不會有異常突然從奇怪的地方冒出來。

如果你是從 JavaScript 轉過來，靜態型別一開始也會讓你覺得很受限。撐過兩個禮拜。之後你在用其他語言的時候反而會想念它。

現在在用它做什麼

目前用 Go 在開發一個代幣閘道（token-gating）API——它會檢查 NFT 持有情況，並為受保護的內容發放已簽名的 session token。Go 的標準函式庫對加密相關操作的支援很好，而且編譯出來的是單一的獨立執行檔，部署超方便。

如果你在做 Web3 後端的東西，還沒試過 Go，真的值得試試看。生態系成熟，語言本身在熟悉之後也真的很好用。

Writing My First ZK Circuit with Circom

Sat, 18 Jun 2022 00:00:00 +0000

The crypto market is down bad right now 📉. But honestly? The bear market is my favourite time to learn. No FOMO, no Twitter noise. Just me, my laptop, and a very long reading list.

I have been talking about zero-knowledge proofs for a while now (see my earlier posts on the STARK prover). This time I actually wrote one from scratch instead of just reading about it.

Why Circom?

I started with Circom because it targets Solidity developers and the tooling around it (snarkjs) is well-documented. There are other options like Noir or Halo2, but Circom felt the most approachable as a starting point.

The mental model that finally clicked for me: a ZK circuit is like a function where you prove you know the inputs that produce a given output, without revealing those inputs. The verifier learns nothing about your private inputs — only that they satisfy the constraints.

My First Circuit

I started with the classic example: prove that you know two numbers a and b that multiply together to give a public value c. Sounds simple, but seeing it work end-to-end made everything concrete.

pragma circom 2.0.0;
template Multiply() {
signal input a;
signal input b;
signal output c;
c <== a * b;
}
component main = Multiply();

After compiling with Circom, running through snarkjs to generate the proving and verification keys, and finally deploying the Solidity verifier contract on a testnet — it worked. The verifier confirmed my proof without knowing what a and b were.

It’s honestly a bit magical the first time you see it. 🤯

What Tripped Me Up

The hardest part was understanding the difference between signals and variables in Circom. Signals are constrained (they form part of your circuit), variables are not. If you mix them up, you get subtle bugs that compile fine but produce incorrect proofs.

Also, the trusted setup phase with snarkjs requires downloading some relatively large files (the Powers of Tau ceremony output). The documentation does warn you but I still sat there wondering why my internet was being hammered.

What’s Next

I want to build something actually useful with this — probably a simple private voting circuit. Also planning to explore Noir from Aztec, which has a Rust-like syntax and might feel more natural given my background with Rust.

ZK is hard, but it’s the kind of hard that feels worth it.

References

用 Circom 寫出我的第一個零知識電路

Sat, 18 Jun 2022 00:00:00 +0000

現在的加密貨幣市場跌得很慘 📉。但說實話？熊市是我最喜歡學習的時候。沒有 FOMO，沒有 Twitter 的喧囂，只有我、筆電和一份超長的閱讀清單。

我已經聊了好一陣子零知識證明的話題了（可以看看我之前關於 STARK 的文章）。這次我終於不只是讀，而是從頭寫了一個實際的電路。

為什麼選 Circom？

我選擇從 Circom 入手，因為它是為 Solidity 開發者設計的，而且配套工具（snarkjs）的文件相當完整。雖然也有 Noir、Halo2 等選擇，但對於剛入門的我，Circom 感覺是最容易上手的起點。

讓我終於搞懂的心智模型是這樣的：ZK 電路就像一個函式，你可以證明自己知道產生某個特定輸出的輸入值，卻不需要透露那些輸入值本身。驗證者只知道「這個人確實知道答案」，但完全不知道答案是什麼。

我的第一個電路

我從經典範例開始：證明你知道兩個數字 a 和 b，它們相乘等於公開的值 c。聽起來很簡單，但親手看到它跑起來之後，一切都變得具體了。

pragma circom 2.0.0;
template Multiply() {
signal input a;
signal input b;
signal output c;
c <== a * b;
}
component main = Multiply();

用 Circom 編譯之後，透過 snarkjs 生成證明金鑰與驗證金鑰，最後把 Solidity 驗證合約部署到測試網——成功了。驗證者確認了我的證明，但完全不知道 a 和 b 是什麼。

第一次看到這個運作的時候，真的有點神奇 🤯

讓我踩到坑的地方

最難的部分是搞清楚 Circom 中「信號（signal）」和「變數（variable）」的差異。信號是受約束的，構成電路的一部分；變數則不受約束。如果搞混了，會出現很難察覺的錯誤——程式能編譯通過，但產生的證明是錯的。

另外，snarkjs 的可信設置（trusted setup）階段需要下載相當大的檔案（Powers of Tau 儀式的輸出）。文件有提醒，但我還是坐在那邊想說網路為什麼突然這麼慢。

接下來的方向

我想用這個建構一些實際有用的東西——大概是個簡單的私密投票電路。另外也計畫探索 Aztec 的 Noir，它的語法有點像 Rust，對我來說可能更自然。

ZK 很難，但這種難感覺是值得的。

參考資源

Generate NFTs based on user's personality

Sun, 17 Oct 2021 00:00:00 +0000

There are so much going on this October. I have two Bootcamps going on at the same time, a two-week-long project, the ETHOnline hackathon and a new start in my career! I am also trying to sell my iPad Pro and a brunch of scammers approached me… gave me a headache.

Btw, let’s get into today’s topic. The half-finished hackathon solo project that I had recently submitted lol!

The original project idea is to build a casual personality test and map some NFTs to the personality results. These NFTs will be minted on a first-in-first-mint basis at a limited quota.

However, I was stuck on the personality test side for a very long time because I am not a psychologist and I don’t know how to design a personality test… After that, I kind of randomly assigned personalities to those Pokemon cards. Then, the NFT part is relatively easy. With the help of the NFTPort, minting to Polygon or the testnet is completely free. Free minting is one of the reasons why I picked NFTPort in the first place. It also supports OpenSea’s metadata configuration and essential features such as NFT storage, which is pretty handy.

However, using third-party services like NFTPort is not a common practice. Especially if you want to design another set of smart contracts to interact with the NFT.

In the following months, I will redesign and add extra features on top of the current project, such as:

NFT staking
Better personality test
One-click NFT listing
Minting monitor
and happy hacking!

Source code is on GitHub.

About Retroactive Public Goods Funding

Sun, 19 Sep 2021 00:00:00 +0000

Karl and Vitalik talked about retroactive public goods funding on the recent EthOnline click-off ceremony.

This idea was raised as we learnt there are lot of coin voting failures, such as the one with EOS and the Hive fork.

The idea of retroactive public goods funding is fund only goes to the public good that showing to have an actual impact. Instead of funding public goods ahead of time, and hope that it’s going to do some good over time.

Project Token

Before the project hit the market, the project team can pre-mined project tokens and sell it on Defi platform like Uniswap, to exchange for tokens for some fundings.
After the project started providing public good value, someone can just buy up these project tokens thereby everyone who holds these tokens will also be benefited from the increase in value.
Legitimacy
Creating value at the same time provide incentive motivation

The Retroactive Public Goods Funding Oracle

Reference

reference #1: Moving beyond coin voting governance

reference #2: ETHOnline 2021 | Kick off Talk Retroactive Public Goods Funding excerpt

reference #3: Retroactive Public Goods Funding

How I learn Rust

Sun, 19 Sep 2021 00:00:00 +0000

From my observation, Rust is a really popular language in not only blockchain but also areas such as gaming where high performance is required. Many of my favourite projects are written in Rust, and it is frustrating when I can’t understand the language… 🥲 This is also my main driving force to study Rust.

I came across few resources on the Rust official site. Making sure that I subscribe to official updates and newsletters. Another source I follow is the Rust in Blockchain site, they also occasionally update their blog which is very helpful to catch up with blockchain-related Rust projects.

Rust - Most Loved Language!

✅ Speed ✅ Safety ✅ Come with Cargo Manager ✅ Come with Error Messages ✅ Efficient C Binding ✅ Treads without Data Races

I am currently going through Easy Rust’s tutorials. It is fantastic so far! I love how David Macleod explains Rust in a very detailed way. I am sure you will like it as well! His tutorials are available on Youtube. If you prefer reading, you can check out his book here.

My planning after the Easy Rust tutorials:

fn main() {
println!("Hello World!");
}

P.S. The best way to learn is to get your hands dirty.

Learn how to write a STARK prover from scratch in Python

Sat, 18 Sep 2021 00:00:00 +0000

Starkware is one of the projects that are always on my watch list. Today, I finally have some spare time to go over one of their stark 101 tutorials to write a stark prover from scratch.

The tutorial is a great material to understand the proving mechanism, in which the verifier is succinct logarithmically using a small amount of computation and the prover is proving in a quasi-linear to achieve efficiency on both sides. In other terms, it is scalable. As the amount of verification scales in a log-squared manner, the computation required does grow but it grows very slowly.

Starkware’s team encourage us to rewrite another set of exercises for stark verifier, or maybe rewrite it using a different recurrence rule, or try a different computational statement to see if it can optimize performance better.

If you would also want to give this tutorial a try. I would recommend first read this article where it explains the mathematical primer. It helps you to pick up the math quicker.

After that, you can explore the course material at the STARK 101 course page and start playing with the jupyter notebooks.

Videos are available here.

Is decentralised online court possible?

Tue, 14 Sep 2021 00:00:00 +0000

I have been brainstorming ideas lately for the Consensys’ Bootcamp final project. This final project is an individual project where students are required to build their own Dapp (decentralised application). NFT is such a hot topic lately that many of my classmates are planning to build NFTs related applications. I am personally interested in the topic of privacy, however, it requires mature zero-knowledge infrastructure and study research papers. It doesn’t sound too realistic that a newbie can achieve it at this point in time.

The idea of a decentralised online court system suddenly came to mind today after I finished listening to the DevNews podcast. I spent the whole afternoon researching how online courts works post-pandemic. Remarkerablely, there is only 46% of the population around the globe have access to the legal system and justice is obviously not something assessable to everybody. Developed countries are forced to transition to an online court system since the pandemic happened. While traditional legal professionals are still figuring out how technologies and automation works, is it possible for the crypto community to form a set of tools for build a decentralised online court system/framework?

Note: This is just some of the research I have done for building my final project. It will likely end up in the trash if things get too complicated or I hit the submission deadline.

Opportunities

Build an open-source online court system that allow everyone around the world to use or fork
Let the legal system become assessable for common people
Explore the possibility of making legal system shared resources through decentralisation
Enable automation, transparency and build trust
Use of smart contracts in the legal field
Every court cases have a unique NFT

Challenges

A lot of technical details involved as someone who doesn’t have a law degree
Require people with expertise

Research

It seems like a decentralised court should be called a decentralised justicial system instead. One of the major contributors in this space are:

Kleros is a good fit for the purpose by providing the infrastructure for dispute resolution. In the next blog, I will dig into the Kleros protocol, and use cases while I continue reading about their protocol. More importantly, is to come up with a final project idea that is not too difficult to build at the same time well-structured.

Some use cases that are on top of my head are:

exam result dispute
legal dispute
family law related
commercial related
customer services related dispute
insurance claims

About

Sat, 24 Apr 2021 00:00:00 +0000

This site is built with Hugo, an open-source web framework written in Go, and deployed onto the decentralised web on IPFS.

About Me

Hello 👋 Welcome to my digital garden! I am an accountant turned developer. I write about Blockchain, Data Analysis, Machine Learning, Zero-knowledge Proof, Decentralised Applications(Dapp) and things that I learnt throughout my programming journey.

Things I do at work:

Building solution for Australia’s NFT market
Go lang for back-end
React and NextJS for front-end

Things that I do outside of work:

Contribute to Open Source Projects
Research on anything privacy-related
Join Hackathons occasionally

Education:

Consensys Blockchain Developer Bootcamp Certificate
Monash University FinTech Bootcamp Certificate
BerkeleyX Professional Certificate in Blockchain Fundamentals
Certified Public Accountant (CPA) Program Australia
Monash University Bachelor of Commerce (Accounting and Finance)

Skills:

Data Analysis - Python | Pandas | NumPy | SQL | Monte Carlo Simulations | Plotly Dash | Streamlit
Machine Learning - SciPy | NLP | TensorFlow | Hugging Face | Keras | PyTorch | Deep Learning
Blockchain - Solidity | Web3.js | Web3.py | Ether.js | Truffle | Ganache | The Graph | IPFS & Filecoin
Web Development - JavaScript | React | Next.js | Tailwind CSS | AWS Lambda/SageMaker/S3
Backend Development - Go | Gin | MySQL | PostgreSQL

Why ZK?

I started to research into alt-tech back in 2019, desperately trying to find a solution and encourage people around me to try out these censorship solutions. The first project that caught my attention is the LBRY protocol, a blockchain network that prioritizes freedom of speech. I have been volunteering for the LBRY Foundation since then. Then I discovered zero-knowledge proof through word of mouth and learn the incredible value it can potentially bring to humanity. Later decided to become a developer and dig deeper into the zk rabbit hole.

關於我

Sat, 24 Apr 2021 00:00:00 +0000

本站使用 Hugo（以 Go 撰寫的開源網頁框架）建立，並部署至去中心化網路 IPFS 上。

關於我

您好 👋 歡迎來到我的數位花園！我是一位由會計師轉型的開發者。我在這裡分享關於區塊鏈、資料分析、機器學習、零知識證明、去中心化應用程式（DApp）以及程式開發旅程中所學到的種種。

工作內容：

為澳洲 NFT 市場開發解決方案
使用 Go 語言開發後端
使用 React 與 Next.js 開發前端

工作以外：

參與開源專案貢獻
研究各種隱私相關技術
不定期參加黑客松（Hackathon）

學歷與認證：

Consensys 區塊鏈開發者訓練營證書
莫納什大學（Monash University）金融科技訓練營證書
BerkeleyX 區塊鏈基礎專業證書
澳洲特許會計師（CPA）課程
莫納什大學商學士（會計與金融）

技能：

資料分析 — Python | Pandas | NumPy | SQL | 蒙地卡羅模擬 | Plotly Dash | Streamlit
機器學習 — SciPy | NLP | TensorFlow | Hugging Face | Keras | PyTorch | Deep Learning
區塊鏈 — Solidity | Web3.js | Web3.py | Ether.js | Truffle | Ganache | The Graph | IPFS & Filecoin
網頁開發 — JavaScript | React | Next.js | Tailwind CSS | AWS Lambda/SageMaker/S3
後端開發 — Go | Gin | MySQL | PostgreSQL

為什麼選擇零知識證明（ZK）？

2019 年起，我開始深入研究替代技術（Alt-tech），尋找能夠抵禦審查的解決方案，並鼓勵身邊的人嘗試這些工具。第一個引起我注意的是 LBRY 協議——一個以言論自由為核心的區塊鏈網路。自此之後我便持續關注 LBRY 基金會。

後來，我透過口耳相傳接觸到了零知識證明，深深被它可能為人類帶來的巨大價值所震撼。這也促使我決定成為一名開發者，深入這條 ZK 的兔子洞。

動力來源

每當失去動力時，我都會聽這首歌。

我不太喜歡曝光在大眾視野中。這些文章與筆記只會發布在這個花園裡。

受到賽博龐克與 Web3.0 運動的影響，我在 2019 年底退出了所有主流社群媒體。你或許還能找到我以前的帳號，但那些帳號已不再活躍。

Regina Chow · Links

Mon, 01 Jan 0001 00:00:00 +0000

Regina Chow · 連結

Mon, 01 Jan 0001 00:00:00 +0000