DEV Community: Marigold

Web3藝術產業入門指南】從Marigold工程師－昀彥的視野，來理解Tezos核心開發中特有的分散式協作方式

Marigold — Mon, 13 Mar 2023 08:35:10 +0000

嗨，大家好，我是 Marigold 昀彥，很榮幸能夠接受到非常專業的 C2X3 的專訪，並與他們分享我在 Marigold 以及 Tezos 的經驗。希望這篇文章能夠對讀者有所啟發，並且讓大家更了解 Tezos 以及 Marigold。再次感謝 C2X3 給我分享的機會，專訪原文可以在這裡找到，也期待未來有更多機會和社群的各位分享。

從學術界毅然決然走入區塊鏈開發，一路從dAPP設計到區塊鏈核心功能開發。現任Tezos區塊鏈核心開發工程師的昀彥，將與我們分享這一路上的過程。
不只培育藝術生態圈，泰卓鏈上的基礎開發也沒有落下

區塊鏈技術似乎有一層神秘面紗，感覺是項高深尖端的科技結晶，更遑論「區塊鏈核心開發」更像是高深的武學祕笈，但其實區塊鏈核心開發，在台灣並不是遙不可及的事情。號稱藝術鏈 — Tezos（泰卓鏈）的核心開發工程師團隊，便赫然發現兩位台灣人。我們這次也很榮幸邀請了其中一位工程師——昀彥，他將跟我們在本文中，分享他觀察到的泰卓鏈跟我們觀察的狀況有什麼不同之處。（簡單說就是泰卓鏈的秘辛分享）

Tezos，又稱作泰卓鏈，這條從法國起家的區塊鏈跟其他鏈的不同之處在於，他們將視野聚焦在藝術生態圈上面，也造就了目前在這條鏈上數位藝術和生成藝術蓬勃發展。當然，像其他區塊鏈一樣，他們正積極發展屬於自己的基礎建設，包含虛擬機的相容、票卷應用甚至是核心開發語言推廣，希望可以改善使用者、甚至是開發者的體驗。目前泰卓鏈的核心開發是由多個開發團隊所共同執行，昀彥所服務的Marigold便是其中一個重要的核心開發夥伴。

本日的區塊鏈領航員——昀彥，原本在中研院程式語言與形式方法實驗室擔任助理，專長是函數式程式語言研究，與其他常見的程式語言不同，函數式程式語言更常應用在航太、金融等需要複雜精細計算的產業中，其中也包括了區塊鏈的核心開發（core dev）。因此，當昀彥想離開學界投入業界闖闖的時候，區塊鏈相關應用開發，便闖進了他的世界。

當時朋友找他一起投件，組了一個小團隊，在Cardano和Tezos之間選擇了Tezos，並加入Tezos Southeast Asia（TSA）的技術開發團隊，主要協助開發一些dAPP的應用。後來TSA的任務由TZ APAC承接，便不再作開發相關。因此，在其他工程師朋友的介紹下，昀彥加入了Marigold核心開發團隊，成為了第一代元老成員。
Marigold團隊照（昀彥提供）
Marigold團隊照（昀彥提供）
泰卓鏈上的核心功能開發團隊之一－Marigold

Marigold是由Gabriel Alfour於2020年11月成立，專注於測試和開發Tezos協議的升級。該團隊皆是遠端協作，且擅長函數式語言撰寫，同時在泰卓鏈合約開發主要使用的程式語言－LIGO，也是由該團隊進行開發和推廣。

核心開發、引導示範、培育更多開發者是Marigold的主要任務。他們幫忙開發功能示範型和生態圈可以使用的dAPP。像是Batcher，一個去中心化交易所（DEX）或是可以執行多簽錢包的Multisig。示範型的dAPP雖然不一定擁有使用情境，但希望可幫助在泰卓鏈的開發者，去想像原有核心開發的功能，怎麼去做應用和延伸，然後透過眾開發者的回饋，來優化改善原有的核心功能。其中像是Tezos的高階程式語言LIGO也由Marigold進行開發，並透過教學網站Tezos Academy來跟開發者們溝通，怎麼使用LIGO去撰寫合約。
講求任務分工和整合的核心開發團隊們

在泰卓鏈上共計有DaiLambda、Functori、Marigold、Nomadic Labs、Oxhead Alpha、TriliTech、Tarides這幾個核心開發團隊，大多是遠端且分散式的協作。Nomadic Labs、Marigold、TriliTech是泰卓鏈上三個最大的開發團隊，各自負責不同的開發項目和主要負責的工作，像是Marigold就是負責核心開發中，將交易以及計算簡化打包上傳到區塊鏈上（Rollup）的部分，另外也會幫忙執行驗證、系統測試等。

在泰卓鏈各開發團隊的溝通，大多以線上會議為主，以分散式和矩陣型的方式執行。有一個主要核心開發小組，成員來自各個不同的開發團隊。在這個小組中可以了解、整合各個團隊的進度，也可確認彼此的工作內容有沒有衝突。每個專案或是功能開發小組，其實也會有來自其他開發團隊的成員，好確保每個功能與功能彼此的聯繫不會出差錯。像是昀彥平時便擔任其中一個功能開發團隊的組長，必須要與其他團隊的成員來溝通項目的進度，或是了解其他開發團隊目前的開發狀況。以技術層面來看，Web3或是區塊鏈的開發沒有什麼不同，從昀彥的角度來看，Web2和Web3最大的不同之處，正是這種分散式的協作方式和文化。

另外，團隊和團隊之間也會因為泰卓鏈基金會（Tezos Foundation）所提出來的任務或需求而整合起來，這也使得泰卓鏈，雖然使用了分散式協作的方式來執行開發，但團隊之間合作緊密，形成一個特有且共治的生態體系。
快速理解泰卓鏈上的專案的執行方式

泰卓鏈基金會常常會開出各種不同條件和任務，以此來作資源的整合。除了核心開發團隊外，也可以吸引各種有趣的專案或是應用開發者加入。通常基金會委託執行的方式可以分成：賞金專案、團隊建置、團隊投案這幾種。

「賞金專案」：由基金會定義專案目標與獎金，有興趣的團隊可以針對這樣的標案來寫投標書，以獲得必需要的初始資源，像是元祖級NFT藝術平台——Hic et Nunc和去中心化交易所——QuipuSwap就是屬於這類專案來獲得初始的執行資源。

「團隊建立」：偶而基金會會針對社群中，已經有共識但是一直沒有人力資源去開發的目標，在社群中找到願意建立團隊的人。再由這個人為起點，建立一個針對該需求的開發團隊。如果該團隊需要基金會資源，還是需要將自己的目標寫成計畫書，並且投案去基金會申請補助，像是Marigold就是在這樣的情境下誕生。

「團隊投案」：通常是團隊本身已經成型且有明確的目標，那就可以向基金會申請資金和資源的協助。在泰卓鏈網站上，都有分類分項的方案和主題，提供各個應用開發團隊去寫企劃書投稿，來獲得額外的資源挹注。

當然，泰卓鏈上也有非常多的自己應用開發團隊靠著自己的力量完成計畫，沒有向基金會申請資源。不過據昀彥表示這樣的情形下，團隊和基金會的互動機會比較少，比較容易變成孤軍奮戰，也比較無法打入現有生態圈。在泰卓鏈的生態圈是非常需要跟其他人整合和互通有無。
Tezos的藍圖（Tezos提供）
Tezos的藍圖（Tezos提供）
重視基礎建設的泰卓鏈有著一個健康的未來

文章的最後，昀彥也給想要踏入區塊鏈產業或是想多了解區塊鏈核心開發的人一點建議。

學習、溝通、描述三項能力，會是在區塊鏈產業工作最寶貴的技能。他認為踏入區塊鏈產業，技術是其次，反倒是願意花時間吸收新知，對事物充滿好奇心的人，才能夠跟上區塊鏈一日千里的速度和變化。另外，這個文化是非常需要願意積極和團隊溝通的人才，主動地找出並提供問題的解決方法。最重要的是描述事件的能力，這個工作環境中，常常需要跟其他團隊說明，自己的團隊正在做什麼、遭遇了什麼樣的問題，甚至是向對方提出需求，都需要良好的描述能力，才能讓個專案順暢地進行。

跟著昀彥走了各開發團隊一圈，我們不難想像泰卓鏈想要帶來的文化和生態。不著急針對使用者應用或是商業行為進行技術開發，反而關注在藝術創作者生態或是提供更多資源在應用開發團隊身上，比起炒作投資，他們更為重視鏈上核心技術的發展。雖然一開始起步緩慢，不像是以太坊可以看到種類繁多的應用發生，但隨著數位藝術和生成藝術在泰卓鏈上的發展，我們開始期待，會不會有更多有趣的未來，在這條擁有豐富多元藝術生態的區塊鏈上面展開。

後記備註：整理一些學習密碼給大家參考

必學函數式程式語言（Functional programming）: OCaml
Shell = OCaml / Rust
Tools = OCaml / Rust / Javascript(typescript)
物件導向: C++; Java; Ruby
指令式: C; C++; Java

Source

Tìm hiểu về Gas dành cho những nhà phát triển giao thức Tezos

Marigold — Tue, 06 Dec 2022 10:04:57 +0000

Tìm hiểu về Gas dành cho những nhà phát triển giao thức Tezos

Mỗi giao dịch trong Tezos đi kèm với một chi phí kèm theo được gọi là gas. Bất cứ khi nào bạn gửi một giao dịch, thuộc nhiều loại hoạt động quản lý "manager operation", bạn sẽ chủ yếu bắt gặp gas trong biên lai giao dịch. Nó cũng xuất hiện trong giao diện giao dịch ví, nơi nó có thể yêu cầu bạn cung cấp giá trị gas tối đa cho phép đối với giao dịch này. Chẳng hạn, bạn có thể thấy điều này nếu bạn gửi một giao dịch thông qua octez-client.

This sequence of operations was run:
      Manager signed operations:
        From: [PUBLIC_KEY_HASH]
        .... snip ....
        Gas limit: 3689
        <<<< snip >>>>
        Transaction:
          Amount: ꜩ0
          From: [PUBLIC_KEY_HASH]
          To: [CONTRACT_HASH]
          <<<< snip >>>>
          This transaction was successfully applied
          <<<< snip >>>>
          Paid storage size diff: 66 bytes
          Consumed gas: 2588.410
          Balance updates:
            [PUBLIC_KEY_HASH] ... -ꜩ0.0165
            storage fees ........................... +ꜩ0.0165
          Internal operations:
            Internal Transaction:
              Amount: ꜩ0
              From: [CONTRACT_HASH]
              To: [PUBLIC_KEY_HASH]
              <<<< snip >>>>
              Consumed gas: 1000.398
              <<<< snip >>>>

Chúng tôi mơ hồ kết nối khái niệm gas với chi phí liên quan đến hành động gửi giao dịch đến chuỗi khối Tezos. Bạn đã bao giờ tự hỏi gas là gì và nó dùng để làm gì chưa? Và với tư cách là nhà phát triển giao thức Tezos, bạn nên lấy những con số như thế nào? Hôm nay trong bài đăng trên blog này, chúng tôi sẽ đi sâu vào vấn đề này.

Gas là gì và nó tốt cho cái gì?

Như bạn có thể đã biết, trạng thái chuỗi khối Tezos được duy trì chung, thay đổi và xác minh bởi những "baker" (trong Tezos, baker làm nhiệm vụ xác nhận các giao dịch trong khối, giống như miner trong bitcoin) tham gia vào một kế hoạch đồng thuận. Quan trọng nhất, sự thay đổi của trạng thái xảy ra khi các hoạt động của trình quản lý được chọn và thực hiện bởi các baker. Chúng bao gồm, nổi bật nhất nhưng không độc quyền, các cuộc gọi đến hợp đồng thông minh. Về bản chất, các baker cung cấp dịch vụ để xác thực và thay đổi trạng thái Tezos một cách an toàn thông qua các quy trình tính toán khác nhau.

Chúng tôi sẽ lấy việc thực thi các hợp đồng thông minh làm ví dụ cho cuộc thảo luận dưới đây, điều này cũng có thể được áp dụng cho tất cả các manager operations khác mà Tezos hỗ trợ. Khi một baker thực hiện một hợp đồng thông minh, có một số hoạt động được tìm thấy theo kinh nghiệm để hạn chế tài nguyên tính toán. Chúng thường chậm và bị giới hạn bởi thời gian của CPU vì nó liên quan đến số học khó (hard arithmetics), chẳng hạn như các phép toán đường cong elip (elliptic curve operations) vốn là trung tâm của mật mã học hiện đại (morden cryptography); hoặc chúng bị giới hạn bởi độ trễ I/O vì có thể cần phải đọc từ đĩa.

Theo hướng dẫn chung, đây là danh sách không đầy đủ các hoạt động trong Michelson được coi là hạn chế tài nguyên.

Truy cập big maps
Phân tích cú pháp Michelson từ đầu vào của người dùng thành biểu diễn bộ nhớ và giải nén chúng trở lại trước khi ghi chúng vào chuỗi
Xây dựng các hoạt động nội bộ (internal operations) để thực hiện các manager operations, chẳng hạn như gọi một hợp đồng từ một hợp đồng khác, điều này chắc chắn liên quan đến việc phân tích cú pháp và hủy phân tích cú pháp như điểm trước đó
Số học đường cong elip bao gồm các hoạt động BLS (BLS operations)
Thao tác các giá trị Michelson, bao gồm đọc và phá hủy các tham số cuộc gọi hợp đồng và kho lưu trữ hợp đồng cũng như ngăn xếp trình thông dịch Vì vậy, danh sách này về cơ bản bao gồm tất cả các hướng dẫn Michelson mà bạn có thể gặp phải khi soạn thảo một hợp đồng thông minh.

Vì các hoạt động đó tốn kém về thời gian, nên chúng mở ra cơ hội chặn tiến trình liên quan đến việc thay đổi trạng thái Tezos nếu thời gian để thực hiện chúng tích lũy trong một lệnh gọi. Điều này gây bất lợi cho hiệu suất của những baker và cuối cùng là toàn bộ chuỗi khối Tezos. Điều này có thể được khai thác thêm để khởi động cuộc tấn công Sybil bằng cách loại bỏ sự đồng thuận của các baker. Để làm như vậy, các đối thủ gửi các hoạt động gọi hợp đồng một cách chiến lược cho những baker để bão hòa thời gian CPU cho họ, với hy vọng loại bỏ những người tham gia trung thực trong giao thức đồng thuận.

Ngoài ra, cung cấp đủ ưu đãi cho các baker để cung cấp các dịch vụ của Tezos như thực hiện các hợp đồng thông minh. Có một thước đo về thời gian cần thiết để thực hiện một cuộc gọi hợp đồng sẽ là một yếu tố quan trọng trong việc đo lường các ưu đãi đối với các baker cho dịch vụ của họ.

Do đó, câu trả lời ngắn gọn cho câu hỏi về bản chất và định nghĩa của gas là nó là một tiêu chuẩn về mức tiêu thụ thời gian để cung cấp dịch vụ Tezos.

Tại sao gas được đặt ở các giá trị này?

Rất cố gắng chỉ sử dụng thời gian CPU thô được đo để áp dụng và bao gồm từng hoạt động của trình quản lý nhận được cho các giá trị gas. Trên thực tế, hầu như tất cả các baker đều không thể sử dụng cùng một thời gian CPU cho một hoạt động cụ thể do các thông số kỹ thuật của máy khác nhau. Ngay cả trên cùng một máy, thời gian để thực hiện cùng một thao tác có thể dao động trong các lần chạy khác nhau do các yếu tố như khối lượng công việc khác đang chạy trên máy và cách hệ điều hành lên lịch cho các tác vụ. Để đo lường mức tiêu thụ tài nguyên máy tính một cách công bằng bất kể sự khác biệt về hiệu suất kim loại trần (bare-metal), một mô hình kế toán trừu tượng được giới thiệu trong mỗi giao thức Tezos.

Sự phức tạp xảy ra khi trên thực tế, hầu hết các hoạt động sẽ mất thời gian khác nhau để hoàn thành tùy thuộc vào đầu vào và các yếu tố khác. Vì lý do này, các giá trị gas được tham số hóa trên một tập hợp các đầu vào, chẳng hạn như kích thước của giá trị Michelson đầu vào nếu chúng đơn giản hoặc kích thước của big map hoặc big map đang được tra cứu. Một ví dụ thú vị là lệnh PACK. Các tham số khối lượng công việc của nó được chỉ định trong Interpreter_model.ir_model. Các giá trị gas của việc thực thi lệnh PACK, tuần tự hóa giá trị thời gian chạy trong khi diễn giải mã hợp đồng thành byte, được mô hình hóa tuyến tính (modelled as linearly depending) tùy thuộc vào số lượng node trong giá trị đầu vào, kích thước của số nguyên và kích thước của chuỗi trong giá trị đầu vào.

Sau khi đưa ra các giả thuyết về mối quan hệ giữa các đầu vào tiềm năng với hiệu suất thực hiện từng lệnh và thao tác, điều còn lại phải làm là tạo các điểm chuẩn khác nhau để đo thời gian chạy của từng thao tác đó nhằm tìm ra các tham số cho mô hình của chúng tôi. Các quan sát sẽ là thời gian tính bằng nano giây được thực hiện để hoàn thành các hoạt động trong các benchmark vi mô (micro-benchmarks) và benchmark khác nhau trong các tình huống khác nhau trên máy cơ sở. Để nâng cao độ chính xác, lasso được sử dụng để tính toán hồi quy tuyến tính (linear regression). Do đó, khi các benchmark này được chạy trên máy cơ sở (base-line machine), thời gian được báo cáo sẽ là số đơn vị gas tiêu thụ cho mỗi lần vận hành.

Vì vậy, để tóm tắt, giá gas trong giao thức được lấy trực tiếp từ số liệu thống kê thời gian chạy của từng hoạt động được coi là đáng để theo dõi trong hệ thống gas. Một bộ benchmark (benchmark suite) được sử dụng và các phương pháp thống kê được áp dụng để loại bỏ nhiễu ngẫu nhiên trong các benchmarks đó.

Tại sao tôi không thể đạt được các giá trị gas giống nhau?

Giả sử sau khi các thay đổi đối với giao thức Tezos được triển khai, bạn chỉ cần chạy tezos-snoop để nhận các số tham số gas mới như được báo cáo bằng cách làm theo hướng dẫn tại đây. Tuy nhiên, nếu các lần chạy được thực hiện cục bộ trên máy của bạn, rất có thể bạn sẽ không bao giờ nhận được các số giống như quy định trong mã giao thức (protocol code). Lý do tại sao điều này xảy ra?

Câu trả lời là bạn không chạy benchmarks trên máy dòng cơ sở (base-line machine). Máy dòng cơ sở hiện được duy trì bởi Nomadic Labs, là một "Dedibox" Scaleway bare-metal dành riêng cho benchmarks ngay trước mỗi đề xuất giao thức để chuẩn bị cập nhật các thông số gas. Thông số kỹ thuật của chiếc máy này hơi hợp lý để nó phản ánh hiệu suất cơ bản của các baker theo nghĩa là mạng Tezos tiếp tục phát triển mà không cần các baker có hiệu suất.

Vì một lý do chính đáng, Mọi người sẽ cảm thấy phần nào đó hợp lý nhưng vẫn không thoả đáng. Cho dù Scaleway cách ly máy dòng cơ bản tốt như thế nào trong quá trình đo benchmarks, thì sự biến động về hiệu suất là không thể tránh khỏi. Nó đang chia sẻ tình trạng tắc nghẽn trên mạng, điều này ảnh hưởng đến hiệu suất truy cập ổ đĩa vì các ổ đĩa trên đám mây có khả năng được gắn từ xa. Vì lý do này, các nhà phát triển Tezos đang xem xét nâng cấp benchmarks giao thức (benchmarks protocol). Cụ thể, chúng ta sẽ thấy một quy trình mới để lấy các giá trị gas đó với sự trợ giúp của các lần chạy benchmark độc lập trên các máy đa dạng. Các số điểm benchmark sẽ được cộng lại với nhau, bằng cách chia tỷ lệ qua lại để bù cho sự khác biệt tương đối về hiệu năng của máy, để cuối cùng tạo ra các giá trị gas.

Source: https://www.marigold.dev/post/gas-for-tezos-protocol-developers

Translation by Ly Kim Quyen, Software developer at Marigold

Những kiến thức cơ bản về Thẻ (vé)

Marigold — Tue, 29 Nov 2022 16:12:24 +0000

Thẻ Tezos (Tezos tickets) là một loại kiểu dữ liệu chung được tích hơp sẵn, với các bất biến mạnh được thực thi bởi hệ thống kiểu. Vậy thẻ là gì? tại sao? như thế nào? và những điều làm cho thẻ được đánh dấu là gì?

Những phần trong bài viết này sẽ giúp bạn hiểu được về thẻ mà không yêu cầu có bất cứ kiến thức chuyên môn về các loại kiểu tuyến tính (linear types), Michelson, hoặc về giao thức Edo (the Edo protocol). Trước khi bắt đầu chúng ta hãy cùng nhau tìm hiểu một số khái niệm dưới đây.

Token là gì?

Đơn vị tiền mã hoá trong Tezos được ký hiệu là: XTZ. Bạn có thể sở hữu nó, gửi nó cho một người khác, sử dụng nó trong các hợp đồng, v.v. Nó giúp thúc đẩy mọi giao dịch, thực thi các hợp đồng thông minh (smart contract). Để giúp dễ hiểu, bạn chỉ cần xem nó như một loại Token cũng được.

Bạn có thể hiểu các Token một cách trừu tượng: Chúng không phải là một thứ cụ thể trong ví của bạn mà chúng được quy định bởi hợp đồng thông minh.. Chúng ta có thể kể đến các loại Token như FA1.2, FA2 hoặc ERC-xxx. Trên thực tế Token là các tiêu chuẩn hợp đồng có các tính chất sau:

có một giao diện chung,
có một tiêu chuẩn siêu dữ liệu,
có một số hướng dẫn không thay đổi khi thực thi.

Về cơ bản, Token là một hàng trong sổ cái (ledger) của một hợp đồng cụ thể, với các đầu vào (entrypoint) được tiêu chuẩn hóa, và với một hy vọng là chúng sẽ hoạt động tốt. Chúng ta sẽ gọi chúng là các Token hợp đồng (token contract).

Nếu bạn muốn giao dịch với các Token, bạn cần phải tương tác với các hợp đồng thông minh chứa các Token đấy. Điều này cũng xảy ra ở các sàn giao dịch, các thị trường, các ứng dụng (dapps), v.v. tất cả chúng đều cần tương tác với Token hợp đồng. Khái niệm mà bạn cần hiểu vể việc tiêu chuẩn hóa Token hợp đồng đó là: Các hợp đồng thông minh khác tương tác với hợp đồng thông minh chưa token dựa vào giao diện đã định sẵn. Mặt khác, các sàn giao dịch cần tạo các cầu nối (bridges) cho những Token mới; nghĩa là phải viết các Token hợp đồng mới. Điều này không phải là không khả thi, nhưng nó không hiệu quả.

Bạn chỉ sở hữu một Token chỉ khi một hợp đồng cụ thể của bạn được lưu trữ trong sổ cái. Token không nằm ở trong ví, mà ví của bạn sẽ tìm xem trong Token hợp đồng bạn có Token nào. Trong trường hợp bạn muốn gửi Token cho một người khác. Bạn không gửi Token trực tiếp, mà bạn sẽ yêu cầu Token hợp đồng làm điều đó bằng cách thay đổi vào những hàng cần thiết trong sổ cái (vì Token được lưu trữ thành từng hàng trong sổ cái). Các thuộc tính của Token bắt nguồn từ việc triển khai hợp đồng: chúng không phải là thuộc tính nội tại của Token, mà chúng phụ thuộc vào mã (code) trong hợp đồng, và cách mà hợp đồng được thực thi. Token không thể bị sao chép, bị đánh cắp, hoặc bị mất chỉ vì Token hợp đồng thực thi các thuộc tính đó.

Gai góc

Việc lập Token bằng một Token hợp đồng duy nhất, để làm được điều này, cần yêu cầu tất cả các hành động trên Token phải được chuyển bởi Token hợp đồng. Hãy lấy một số ví dụ sau:

Token hợp đồng là một ví dụ của một thất bại. Điều này không ảnh hưởng trực tiếp đến vấn đề bảo mật, vì hợp đồng được công khai và mọi người có thể kiểm tra các Token là không có lỗi (no bugs), không thể thay đổi. Bản chất của "không thay đổi" có thể là một vấn đề nếu ban đầu Token hợp đồng không hoàn hảo. Để khắc phục điều đó, chúng ta có thể thêm vào các trình bao bọc (wrappers), và cần có sự tin cậy hoặc một mô hình quản trị nào đó (điều này sẽ làm tăng thêm độ phức tạp của Token hợp đồng).

Vì mọi thứ được thực hiện với Token điều phải thông qua Token hợp đồng, điều này làm Token được tập trung (centralize) cao trong hệ sinh thái (ecosystem). Một giao dịch đơn giản như trao đổi Token thực sự liên quan đến nhiều giao dịch giữa cả người dùng và Token hợp đồng như: kiểm tra, chuyển nhượng, những giao dịch giữa những người dùng, xử lý lỗi, v.v. Có một trường hợp ứng dụng trong thực tế phức tạp hơn nhiều so với một loạt các giao dịch trực tiếp vì nó liên qua đến các ứng dụng (dapps). Ngoài sự phức tạp của trải nghiệm người dùng (User Experience - UX), nó còn có thêm chi phí tiêu thụ gas trực tiếp vốn tồn tại trong quá trình tập trung hóa. Những vấn đề này hoàn toàn bị che đi bởi sự đơn giản hóa về "Token trong ví của bạn".

So sánh Token XTZ và các loại Token khác

Để có một cái nhìn tổng quát, chúng ta sẽ so sánh một số điểm quan trọng giữa Token dựa trên hợp đồng thông minh với Token XTZ có sẵn trong hệ thống.

Token	Bộ lưu trữ	Giá trị	Quyền sở hữu	Gas OH	Tích hợp có sẵn
XTZ	Phi tập trung	Protocol	Protocol	Không	Có
FAxxx	Tập trung	Token hợp đồng	Token hợp đồng	Cao	Không

Chúng ta lần lượt giải thích về những đặc tính trên: Bộ lưu trữ và Gas Overhead (Gas OH) có thể giải thích như sau:

Yêu cầu gọi (call) một hợp đồng sẽ luôn tốn kém hơn về không gian và thời gian so với một giao dịch trao đổi các mã XTZ với nhau.

Tích hợp có sẵn nghĩa là được hỗ trợ riêng trong giao thức (protocol): nó được lập trình sẵn, có hướng sử dụng chuyên biệt, v.v.

Về tính tin tưởng chúng ta có hai thành phần:

Quyền sở hữu, ví dụ như mức tối thiểu chúng ta cần tin tưởng/kiểm tra/xác minh để thuyết phục bản thân rằng Token không thể bị đánh cắp (điều này cũng tương tự như việc tin tưởng vào một hợp đồng thông minh cũng đòi hỏi phải có sự tin tưởng vào giao thức).
Giá trị của Token, ví dụ chúng ta có thể thuyết phục bản thân rằng không ai có thể đột nhiên tạo ra một lượng lớn Token có thể thay thế được từ một nguồn nào đó.

Thẻ là gì?

Vậy thẻ là gì? có thể hiểu tóm tắt, thẻ là Token trong ví của bạn, nó là một first-class trong hợp đồng thông minh. Nó cần phải được tạo ra bởi hợp đồng, và cần có một ứng dụng (dapps) để có thể được sử dụng hiệu quả, nhưng nó có thể được lưu trữ bên ngoài hợp đồng tạo ra nó, nó có thể được đính kèm vào bất kỳ tài khoản (account) nào và được trao đổi một cách đáng tin cậy giống như khi trao đổi Token XTZ.

Cụ thể về thẻ

Trước hết về mặt lập trình, có thể hiểu thẻ là giá trị (value) của ngôn ngữ hỗ trợ viết các hợp đồng thông minh, ví dụ như: thẻ 'a ticket trong ngôn ngữ CameLIGO, hoặc ticket cty trong Michelson một loại dữ liệu được tích hợp sẵn với các hàm tạo cụ thể. Giá trị của thẻ kiểu t cho bất kỳ kiểu type t có thể so sánh bao gồm:

giá trị t là giá trị được kiểm soát trực tiếp bởi hợp đồng,
chúng có thể được gửi đến các hợp đồng khác ,
và có thể mang thông tin.

Thẻ có các giá trị bất biến mạnh mẽ được thực thi bởi kiểu hệ thống (type system) được thực thi bởi bất kỳ thẻ nào gắn với một ngữ nghĩa (semantic) và một giá trị được chia sẻ bởi toàn bộ hệ thống chuỗi khối. Những giá trị đó là:

nó không thể được sao chép,
nó không thể bị thay đổi,
nó không thể bị giả mạo.

Một hợp đồng nào vi phạm những giá trị trên sẽ bị kiểu hệ thống (type system) loại bỏ. Thẻ là một loại kiểu tuyến tính (linear types) và thẻ có thể là bất kỳ kiểu nào. Ví dụ, trong LIGO, một giá trị biến có thể chứa thẻ có thể sử dụng một lần, những khái niệm mở rộng về những tính chất này sẽ được đề cập thêm vào phần sau của bài viết.

Trong phần này để đơn giản chúng ta giả sử rằng kiểu hệ thống của chúng ta không cho phép sao chép, nghĩa là nếu một hợp đồng gửi một thẻ đến bất kỳ nơi nào, thẻ này sẽ không thể bị sao chép bởi bất cứ ai, người sử dụng hay các hợp đồng thông minh. Điều đó có nghĩa là đây là một thẻ duy nhất: người tạo ban đầu của thẻ (chủ sở hữu) có thể tạo ra bất kỳ số lượng thẻ nào người đó muốn, nhưng chỉ có người đó mới có thể làm được điều đó, những người khác không thể làm được.

Thẻ không thể bị làm giả, nghĩa là không thể tạo hoặc thay đổi thẻ. Tóm lại, tính chất tin cậy của thẻ là có thể biết thẻ này đến từ đâu và tin tưởng rằng không ai có thể can thiệp vào thẻ này cả. Những thuộc tính này làm cho thẻ trở thành một trong những lựa chọn tự nhiên để triển khai Token:

có thể gửi + nhưng không thể sao chép = có thể chuyển giao quyền sở hữu.
có thể chia sẽ ngữ nghĩa (semantics) + có thể mang bất kỳ giá trị nào = Token.

Hơn thế nữa, chúng ta có thể thay đổi cách thực hiện các giao dịch với Token. Ví dụ: không bao giờ cần kiểm tra xem người dùng có sỡ hữu Token hay không, vì nó được cung cấp trực tiếp và có thể được thao tác trực tiếp.

Những biện pháp bảo vệ đó được cũng cố bằng thuộc tính Ticket hardening trong đề xuất của Itaca2 và Jakarata2.

Thẻ autopsy

Các loại thông tin được lưu trữ trong thẻ bao gồm:

Người bán thẻ (ticketer): chỉ địa chỉ của hợp đồng đã tạo ra thẻ,
khối hàng (payload): về mặt lập trình đó có thể là bất kỳ giá trị của bất kỳ kiểu (type) nào có thể so sánh được.
một số lượng (amount): đó là một số tự nhiên, thể hiện "khối lượng" (volume) và "trọng lượng" (weight) của một thẻ. Ví dụ: khi bạn muốn kết hợp (join) hai thẻ tương thích với số lượng x và y, bạn sẽ nhận được một thẻ với tổng số lượng "x + y". Khi bạn cần chia (split) một thẻ có tổng khối lượng/trọng lượng "x + y", bạn sẽ nhận được hai thẻ, lần lượt với số lượng là x và y.

Ticketer và payload là cố định và không thể thay đổi một khi thẻ đã được tạo. Số lượng sẽ không thay đổi, nhưng với tính chất này có một số ý kiến muốn nó có thể thay đổi. Vì tính phức tạp của ngôn ngữ lập trình, hiện tại tính chất của số lượng chỉ cho phép kết hợp (join) và chia (split).

Payload cung cấp về loại kiểu (type) của thẻ, ví dụ: một thẻ với một payload 1n là một thẻ có kiểu số tự nhiên, và payload 2n cũng vậy. Kiểu payload không bị ràng buộc vào số tự nhiên, mà nó có thể là bất kỳ một kiểu nào, và kiểu đó phải là kiểu có thể so sánh được (comparable). Một trong những kiểu so sánh được có thể đề cập đến là kiểu address và số tự nhiên nat.

Các kiểu so sánh được trong Michelson: trong Michelson kiểu có thể so sánh được là COMPARE, nó được định nghĩa là một kiểu cơ bản (int, string, bytes nhưng nó cũng có thể là các kiểu address, signature, ...) và kết hợp với (option <comparable type> hoặc kiểu <pair>, v.v.).

Kiểu và Khóa

Một kiểu chung của thẻ là 'a ticket trong đó 'a là loại kiểu được định nghĩa trong payload. Thẻ của cùng một kiểu có thể kết hợp (join) nếu nó có cùng ticketer và cùng một kiểu trong payload. Ví dụ: kiểu payload là string ticket, các thẻ: TICKET(bob, "toto", 42), TICKET(jim, "toto", 42), TICKEt(bob, "otto", 42) là có cùng một loại kiều payload (string ticket), nhưng chúng không thể tương thích với nhau vì chúng có các ticketer khác nhau (bob, jim) hoặc khác kiểu payload.

Một số ví dụ cụ thể:

TICKET(bob, "toto", 42) + TICKET (bob, "toto", 69) -> TICKET(bob,"toto", 111)
TICKET(jim, "toto", 42) + TICKET (bob, "toto", 69) -> ERROR
TICKET(bob, "otto", 42) + TICKET (bob, "toto", 69) -> ERROR

Tóm lại, một ticket key: một khóa (key) là một ticketer và có giá trị payload. string ticket có một số khóa (string là kiểu của payload): string của ticketer và string của kiểu payload, ví dụ như các thẻ (bob, "toto"), hoặc (bob, "otto"), hoặc (jim, "toto"). Các thẻ có cùng khóa có tính chất kết hợp (join) và chia (split). Tuy nhiên, có một số trường hợp đặc biệt, các thẻ có cùng một kiểu nhưng không thể kết hợp được với nhau, muốn kết hợp các thẻ với nhau chúng phải có cùng ticketer và giá trị payload.

Chúng ta nhắc lại một tính chất của thẻ đó là không thể thay đổi ticketer và cũng không thể thay đổi payload. Vì hai tính chất này, thẻ khóa là không thể thay đổi.

Vì thẻ không thể thay đổi, chúng chỉ có thể kết hợp hoặc chia, một hợp đồng có quyền kiểm soát rõ ràng đối với thẻ của tất cả các khóa được gán cho nó; và người nhận thẻ điều biết được thẻ này đến từ đâu. Ví dụ: để tạo một Token có thể thay thế (fungible token), người ta có thể mint một hợp đồng, và tạo ra các thẻ với payload cố định. Những thẻ này có thể được gửi cho người dùng mà không mất đi dấu của tổng số lượng, và bảo đảm rằng không ai có thể chỉnh sử thẻ này (ví dụ: tạo ra thẻ mới mà không biết ticketer chẳng hạn).

Linear type

Các giá trị bất biết có thể bắt nguồn từ nhiều nguồn. Ví dụ, các đoạn mã lập trình (code) của một số ngôn ngữ lập trình hỗ trợ strong typed. Trong phần này, chúng ta sẽ xem xét một số hệ quả thực tế của nó. Biến số (variable): sử dụng chúng hoặc bị mất.

Để hiểu kiểu bất biến (linear type), chúng ta có thể hình dung biến số (varible) khi được tạo ra được sử dụng chỉ duy nhất một lần. Và khi đã được sử dụng, chúng sẽ mất đi (không thể sử dụng lại được nữa). Ví dụ:

let ticket = ... in
let copy = ticket in 
ticket, copy

Đoạn mã lập trình trong ví dụ trên sẽ báo lỗi trong:

LIGO: warning: variable "ticket" cannot be used more than once (cảnh báo: biến số "ticket" không thể được sử dụng nhiều hơn một lần.)
Michelson:

Ill typed contract: type ticket nat cannot be used here because it is not duplicable. Only duplicable types can be used with the DUP instruction and as view inputs and outputs

(Kiểu hợp đồng yếu: kiểu thẻ nat không thể được sử dụng bởi vì chúng không thể bị sao chép. Chỉ có loại kiểu được sao chép mới có được sử dụng với DUP và với view đăng nhập và đăng xuất)

Điều đó có nghĩa là các hàm khai báo có thể khai báo thẻ là một đối số (argument) và hàm này cần phải có giá trị trả về nếu không nó sẽ bị mất đi. Lấy ví dụ của hàm read_ticket sau đây là không thể áp dụng:

let ticketer, payload, amount = read_ticket ticket in 
...

Nếu không, một khi thẻ đã được đọc nó sẽ bị mất/đốt cháy (burned) vĩnh viễn. Trong thực tế, hàm read_ticket được sử dụng như sau:

let (ticketer, (payload, amount)), new_ticket = Tezos.read_ticket ticket in 
...

Constructors

Để tạo ra thẻ mới, có thể sử dụng constructors: create_ticket, split_ticket và join_ticket.

Trong LIGO, các hàm này như sau:

val create_ticket: 'value -> nat -> 'value ticket
val split_ticket : 'value ticket -> nat * nat -> ('value ticket * 'value ticket) option
val join_tickets : 'value ticket * 'value ticket -> ('value ticket) option

create_ticket: hàm này sẽ tạo mới thẻ (trong ví dụ dưới đây, kiểu của thẻ có thể được suy ra, và chúng được đưa ra để phân biệt giữa kiểu và khóa)

let new_ticket : string ticket = Tesoz.create_ticket "some payload" 42n in
...

split_ticket: chia một thẻ thành các thẻ mới có cùng khóa

let old_ticket  = Tesoz.create_ticket "some payload" 42n in
let opt  = Tesoz.split_ticket old_ticket (12n,30n) in
let ticket_12, ticket_30   = Option.unopt opt in
    ...

join_ticket: kết hợp hai thẻ có cùng khóa vào làm một thẻ

let ticket_12  = Tesoz.create_ticket "some payload" 12n in
let ticket_30  = Tesoz.create_ticket "some payload" 30n in
let opt  = Tesoz.join_tickets (ticket_12,ticket_30) in
let ticket_42 = Option.unopt opt in
    ...

Tìm kiếm bộ lưu trữ

Nếu thẻ có kiểu là map, thì không thể tìm thẻ và để nó ở trong map. Nếu bạn muốn truy suất thẻ, trước tiên bạn phải xóa thẻ từ trong map. Đó là lý do tại sao chúng ta sử dụng hàm get_and_update, với kiểu None được xem như giá trị mới:

let ticket,store_without_ticket = 
    Map.get_and_update addr (None : silly option) store in 
    ...

Cập nhật bộ lưu trữ

Trong khi cập nhật, hàm get_and_update, nếu có giá trị mới nó sẽ trả về giá trị Some ticket cho thẻ là None. Ngược lại, nó sẽ bị trùng lặp:

let _ticket,store = Map.get_and_update addr (Some silly) store in 
    ...

Giá trị _ticket có giá trị trả về là None.

Views

Onchain views (chế độ xem onchain) là một cơ chế tích hợp để cung cấp quyền truy cập đồng bộ, cho phép thuộc tính chỉ đọc vào hợp đồng thông minh. Chế độ xem (views) hơi giống endpoint ở chỗ chúng lấy giá trị của (parameter * storage), nhưng thay vì trả về operation list * storage, views có thể trả về bất kỳ giá trị nào mà không làm ảnh hưởng đến bộ lưu trữ.

let main (action,store : sc_parameter * storage) : operation list * storage = ... 

[@view] let view_1 (parameter,store : view_parameter * storage) : view_return_value = ...

Parameter (view_parameter) và giá trị trả về view_return_value có thể có bất kỳ kiểu nào ngoài các kiểu sau: big_map, sapling_state, operation, ticket

So sánh lần nữa giữa: XTZ, Token và thẻ

Token	Bộ lưu trữ	Chủ sở hữu	Giá trị	Có sẵn	Gas OH
XTZ	Phi tập trung	Protocol	Protocol	Có	Không
FAxxx	Tập trung	Mã hợp đồng	Mã hợp đồng	Không	Cao
Thẻ	Phi tập trung	Protocol, hợp đồng	Hợp đồng	Có	Tùy

Bộ lưu trữ của thẻ có thể là phi tập trung, và thẻ có thể được trao đổi giữa các hợp đồng. Hơn thế nữa, việc tạo ra các thẻ là hoàn toàn tập trung, và có thể lưu trữ các thẻ với một khóa ở một chỗ: chỉ không phân tán và được lưu trữ trong sổ cái.

Về tính chất tin tưởng, nếu chúng ta chọn chủ sỡ hữu và giá trị để so sánh:

Tin tưởng chủ sở hữu trong trường hợp này đơn giản hơn, nó có một hợp đồng lưu trữ thẻ cần được tin tưởng.
Tin tưởng vào giá trị tùy thuộc vào sự sử dụng của thẻ, nhưng trong mọi trường hợp, nó sẽ phụ thuộc vào tính đúng đắn của các hợp đồng sử dụng thẻ.

Gas overhead (Gas OH) một lần nữa phụ thuộc vào kiến trúc đã chọn cho một trường hợp sử dụng cụ thể. Càng ít tập trung, thì chi phí gas càng ít. Sẽ có một số Michelson được thực thi để thao túng thẻ, vì vậy sẽ có mức tiêu thụ gas, nhưng có thể ít hơn. Một lần nữa, nó tùy thuộc vào việc triển khai và kiến trúc.

Hạn chế: Kể từ tháng 5 năm 2022, thẻ có thể được giữ bởi các địa chỉ ban đầu (địa chỉ của các hợp đồng thông minh) nhưng hạn chế này sẽ được loại bỏ trong một đề xuất trong tương lai. Layer 2 Tezos như TORUs, SCORUs, DEKU hoặc Chusai (sắp ra mắt) đã có thể giữ vé cho các tài khoản ẩn (implicit account) (tz1xxx, tz2xxx, tz4xxx).

Thẻ trong Tezos Layer 2

Hệ sinh thái tầng 2 (Layer 2 ecosystem) của một số chuỗi khối, bạn sẽ nhanh chóng nhận ra có một khó khăn đó là khó khăn khi phải kết nối các cầu nối (bridge) với Token với các token của tầng 2. Chuyển giao các nội dung giữa các tầng là một điều khó khăn.

Khi thẻ là một first-class trong tầng 2 của Tezos, điều này sẽ mang lại rất nhiều sự đơn giản và tránh được nhiều khoảng phí vô ích cho việc khóa/mở khóa trong chuỗi chính (main chain). Nó cho phép tất cả các tầng 2 trở thành "bất khả thi về Token" và thao túng các thẻ bất kể nguồn gốc cũa chúng, miễn là các Token được triên bằng thẻ, nó được hỗ trợ bởi tất cả tầng 2, miễn phí mà không cần bất kỳ cơ sở hạ tầng chuyên dụng nào. Nếu không, chỉ cần một hợp đồng cung cấp thẻ cho Token (lưu trữ trong kho (vault)) là đủ.

Chúng ta hãy tưởng tượng:

Bạn có một hợp đồng cần được mint một thẻ cTez, kho CTez là một kho lưu trữ của hợp đồng với thẻ này.
Bạn có thể gửi thẻ này vào TORU rollup.
Sau đó thực hiện một giao dịch với một số lượng cụ thể.
Sau đó rút số lượng còn lại của thẻ vào Tezos.
Sau đó gửi tiền vào DEKU sidechain.
Sau đó, sử dụng thẻ với một hợp đồng thông minh.
Rồi, rút về Tezos và cuối cùng đốt thẻ đó từ ticketer ban đầu với cTez còn lại.

Bạn có thể sử dụng Tezos, optimistic rollup và sidechain cho cùng một thẻ!

Cách suy nghĩ về thẻ

Để kết luận, có một số ví dụ hữu ích để suy nghĩ về thẻ: nó là một suy luận về ngữ nghĩa của một hợp đồng, nó là một thử nghiệm các cách mới để triển khai các chức năng hiện có, nó truyền đạt các khái niệm.

Một phần dữ liệu không thể giả mạo và có thể theo dõi
Tiền mặt, nó ở trong túi của bạn nhưng nó không thể làm giả được
Chìa khóa để mở các chức năng
Một phương thức cho chuỗi khối hỗ trợ bất kỳ Token tùy chỉnh nào
Token hoạt động như dự định
Một vật phẩm đồng bộ hóa để xử lý đồng thời
Một công cụ để ghi dữ liệu vào sổ cái toàn cầu: nơi dữ liệu được lưu trữ không làm thay đổi ý nghĩa/giá trị của thẻ
Dữ liệu có thể được lập luận ở cấp độ của toàn bộ chuỗi khối, không chỉ ở cấp độ của hợp đồng
Loại dữ liệu hợp đồng thông minh với các bất biến rất mạnh

Đã đến lúc bạn sử dụng thẻ trong Tezos ngay bây giờ.

Source: https://www.marigold.dev/post/tickets-for-dummies

Translation by Ly Kim Quyen, Software developer at Marigold

Tezos的加德滿都協定將打開與以太坊虛擬機(EVM)相容的大門

Marigold — Mon, 07 Nov 2022 11:33:34 +0000

Oct 19 (edited)隨著「加德滿都（Kathmandu）」於上個月（9/24）成功升級，Tezos 已經成完成 11次的升級，距離上次「雅加達」（Jarkata）升級也不過相隔不到三個月。加德滿都為尼泊爾首都，延續了一直以來 Tezos 用古城名來命名協定的傳統，積極的更新並釋出新的協定階段，也向來是 Tezos 的特色。這裡幫大家整理一下，加德滿都協定的五個重要更新方向。
取自 https://news.coincu.com/
隨著「加德滿都（Kathmandu）」於上個月（2022/09/24）成功升級，Tezos 已經完成 11次的升級，距離上次「雅加達」（Jarkata）升級也相隔不到三個月。加德滿都為尼泊爾首都，延續了一直以來 Tezos 用古城名來命名協定的傳統；積極地更新並釋出新的協定階段，也向來是 Tezos 的特色。
而此次升級，最重要的是引入了對 WASM（WebAssembly）的直接支援，並且對 EVM（Ethereum Virtual Machine）智能合約虛擬機的相容打開了可能性。這讓人期待在未來，Tezos 的虛擬機 Michelson 將擁有一個可以運行所有程式的作業環境。（可以簡單的想像，未來在 Tezos 可以直接跑 ETH 上面的智能合約）
這裡也幫大家整理一下，加德滿都協定的五個重要更新方向：

新一代的 optimistic rollups optimistic rollups 是 Tezos 鏈上一種快速將交易以及計算簡化打包上傳到區塊鏈上的方式，避免了所有動作或是無謂的資訊都強迫在鏈上執行的不便。而這次升級，在於可以更大量的來執行 rollup 的動作，主要就是針對開發者可以更好、更方便地來使用，也為打開與其他智能合約虛擬機器（例如 EVM）的相容，做了一個不錯的開端。
新增智能合約的事件日誌機制 Event logging 這次更新，新增了一個 Michelson 指令：EMIT。藉由這個指令，合約可以在執行期間送出一筆可以作為紀錄的資訊，被稱為「合約事件」 (contract event) ，記錄合約動作的摘要。此種新的資料使用形式不會儲存在合約空間中，而是儲存在合約運算結果的收據（receipt）上。由於不會進入合約空間，可以節省掉不必要的合約空間費用（storage fee）。
管線化區塊驗證（pipelined block validation）的第一步這個更新的重點是簡化區塊驗證的過程，減少在鏈上完全執行合約的需求，可以省錢也可以省時，也可以增加 Tezos 的吞吐量，並同時保有區塊鏈的安全性。加德滿都中實踐了管線化區塊驗證的第一步：將鏈上交易的執行與驗證更好地獨立開來。基於這個更新，未來可以進一步加速區塊驗證。
永久測試網過往 Tezos 的測試網不會隨著不同階段更新，對於開發者來說其實有著一定的不便，需要常常切換最新的測試網（像是Hangzhou testnet已經停用）。但現在，Ghost net is live!! 開發團隊原地將 Ithaca testnet 改為 ghost tesnet，作為開發者的長期使用。此外，ghostnet 會自動更新至最新的協定，如此一來開發者就不需要手動在不同測試網路中切換。
協定上隨機演算法的改善 Tezos 原先使用類似 RANDAO 的機制來作為亂數產生機制。此更新中加入了對於 VDFs（Verifiable Delay Functions）的支援。不同於 RANDAO 的類亂數產生機制，VDFs 是一種可驗證的延遲函數，這個改善主要加強了 Tezos 協議的分散式隨機性生成機制。聽起來有點複雜，但主要用意就是增加了區塊鏈的安全性。總之，更新的目的就是要讓這條鏈，處理速度更快、操作手續更省錢、開發者更方便使用、相容度更高，但使用性更安全，也讓我們可以期待 Tezos 接下來的發展 :)

註1：Tezos 升級由全球開發者團隊、Tezos 社群、烘焙師以及 Nomadic Labs、Marigold、TriliTech、Oxhead Alpha、Tarides、DaiLambda、Functori & Tweag 的關鍵協定團隊支持。
註2：主要更新資訊內容感謝 Marigold 提供協助。

c2x3除了會在Matters上分享台灣NFT項目，也致力將台灣項目推向國際！如果喜歡我們的內容，誠摯邀請大家分享我們的文章，讓更多人看見！我們也會出現在 Facebook，還有英文版的Twitter 跟 Medium，請記得幫我們按讚訂閱加分享。
c2x3下次再見！

Source