Programming Language Notes

  開發之前我們先來做一些前置準備，就如同一道料理在完成之前，會預先準備廚具、食材，而我們就來看看這些廚具與食材究竟能夠煮出什麼令人驚豔的料理吧！ 那我們需要準備哪些東西呢？ IDE： 基礎版( Remix )、進階版( Vscode )。 程式語言： Solidity 。 程式碼儲存庫： Github 。 簡易Demo Remix線上編輯器 這邊我們會以最簡單的方式進行Demo，後續再使用更進階的編輯器，讓我們開發速度更飛快，目前的趨勢是雲端化，就連開發工具也能夠在雲開發，而Remix IDE也提供了雲端版本，就讓我們來試試看吧！ 首先我們打開Remix IDE( https://remix.ethereum.org/ )，打開之後介面非常簡單的分類成以下幾塊： 圖片來源 這個架構非常的乾淨，權責分明，不會導致初學者混淆。 幾乎不用任何安裝，就讓我們從這裡開始吧~~~ 結合Github讓學習更有軌跡可循 Github 是開發人員常用的一個平台，幫助我們儲存開發的程式碼，而且結合Git進行版本控制，非常的便利，也非常鼓勵大家註冊，一邊學習一邊累積自己的技術能力，為自己的作品集增添一些豐富度吧！ 接下來我們會示範如何結合Solidity、Remix、Github來完成一個小型的智能合約範例。 建立一個專屬的Github Repository 開發之前我們就先創一個專屬空間來存放我們辛辛苦苦學習的程式碼吧！ 在首頁的左上角可以看到一個「New」的按鈕，按下去之後就可以順利建立專屬的程式碼儲存空間囉。 圖片來源 核發Github通行證(Access Token) 首先我們要讓Remix編輯器能夠順利的存取Github上面的程式碼，此時就需要具有存取通行證，而這個通行證我們就稱為Access Token，那麼就先回到Github上來核發通行證吧！ 帳號註冊完畢後，我們來這裡「 https://github.com/settings/tokens 」簽發Token如下： 圖片來源 接下來分別輸入Token名稱(自己容易識別的名字即可)、過期時間與權限範圍， 權限範圍的部分基本上只要把repo的存取權勾選起來即可。 圖片來源 接著會得到一組Token，這一組Token非常重要，建議先找個記事本記起來，接著會拿這組通行證去Remi

  圖片來源： Solidity 上一篇我們介紹了智能合約的基本概念，而在開發智能合約之前， 建議先對智能合約具備基礎的概念， 往後進行開發時較容易融會貫通， 還沒閱讀的朋友可以參閱此篇「 【開發智能合約 - Solidity系列】 淺談智能合約 」。 理解完「智能合約」之後，相信大家已經開始手癢了吧！ 應該很想開始動手完成第一個自己專屬的「智能合約」，而在開始之前應該要來選個好用的開發工具，至於為什麼要選用 Solidity 這套程式語言？ 主要是開發門檻比較容易入門，參照了 ECMAScript 的語法概念，相信常常在撰寫Web的朋友應該非常熟悉，不僅如此亦加入了靜態的概念，讓程式開發的過程中更加安全穩定，而 Solidity 也是目前區塊鏈程式開發相對熱門的一門技術，因此相信很多問題都會有許多開發者共同討論，在技術的道路上也比較不孤單。 其實撰寫智能合約的程式語言並非只有 Solidity ，還有以下幾個程式語言： ● Vyper ： 相似於Python風格的程式語言，出生的時間比 Solidity 晚，因此相關的討論與教學文章相對較少。 ● Serpent ： 文檔相對少，目前官方也建議棄用。 ● LLL ： 看起來是非常艱澀難懂的程式語言，可能是組合語言級別的大神較容易上手吧。 簡單的智能合約範例 在進入實戰開發之前，我們可以先來看一段簡單的程式碼，相信非常容易理解與開始，讓我們無痛的跨出第一步吧！ // 指定版本至少0.4.16，最多不超過0.9.0 pragma solidity >=0.4.16 <0.9.0; // 合約類別 contract SimpleStorage { // 宣告uint型態的變數 uint storedData; // 提供設定變數的功能函數 function set(uint x) public { storedData = x; } // 提供取得變數的功能函數 function get() public view returns (uint) { return storedData; } } 有沒有發現，撰寫類別與內部函數的方式很像我們常用的Typescript，相信平常有在接觸的朋友應該是非常容易上手的。

  為什麼會有合約的誕生？ 大家想過這個問題嗎？ 試想，當陌生人與陌生人之間如果要產生與金錢相關的交易時，在沒有第三方機構的見證下，我想一般人應該也會存在著「不信任」的狀況產生，因此造就了「合約」的誕生，而這個「合約」主要目的在於確保雙方能夠在不損害對方的利益下完成交易的一種約定，其中包括了雙方的資訊、條款的內容、有效期限、簽名的不可變動性，滿足這些條件後方可形成「合約」，並由第三方機構進行認證來增加公信力。 既然已經有合約的產生，那又為什麼還要創造智能合約呢？ 究竟相較於傳統合約之下，更為優勢的原因在哪裡呢？ 我們將在以下逐一進行說明。 首先來談談傳統合約 圖片來源： 自行製作 在開始說明智能合約之前，我們先來了解一下合約的本質，什麼是合約？ 其實「合約」常常出現在我們的周遭，就以買房來說，買賣雙方簽訂契約後，會需要許多第三方機構的保證才能讓雙方安全的完成交易，諸如： 建商、銀行、代書…等，這些第三方雖然保障了雙方交易的安全性，但某一方如果發生問題也會連帶影響，況且尚未完成交易之前就支付了許多費用給這些第三方單位，有沒有可能讓這個過程更加簡單，並且更加安全呢？ 答案是有機會的，智能合約就是為了滿足這樣的需求而生，當然在這裡並不是說「智能合約」就是完美無缺，我們看到好處之外，也得了解現況與缺陷，才能不會被艱澀難懂的技術名詞給誤導了。 再來看看智能合約 圖片來源： 自行製作 我想智能合約與傳統合約最大的差異就在於沒有第三方機構的介入，一但合約成立、條件滿足，雙方的交易自然得到保障，驗證、不可竄改、自動金流…等，這些過往在傳統合約的組成中，還會分別依賴外部，因此就會產生所謂的手續費，而且過程中也未必具備公平性，但在智能合約的世界裡，由於一切皆由程式執行，只要確保條件沒問題自然就不會有例外狀況，這也就是為什麼大家都在談的「去中心化」的主要核心，但值得注意的是條件必須符合合約的需求，否則需求讓的落差也是一種例外狀況。 可以用在哪些領域？ 金融 智能合約非常適合用於金融領域，交易過程中的不信任是過往遇到的最大挑戰，因此造就了無數個第三方機構，就為了保障雙方的可信任度，一但智能合約引入之後，打破了第三方的存在，讓交易雙方直接溝通，過程中透明、不可竄改，對於金融領域來說真的是一大福音，但對於傳統的金融體系卻是一大挑戰，也是較難盛行的原因。 保險 試想我們平常遞繳保險費用就是為了在

  軟體開發過程中常常會需要將資料儲存於「資料庫」之中，開發程式的過程中一定會頻繁操作資料庫進行資料的儲存與查詢，試想每次的動作如若都要先有連接及斷線的程序，對於資料庫與程式端來說都是一大負擔，因此連接池的機制就是為了減少不斷的連接、斷線的成本，除此之外，也讓連線可以重複使用，減少資源的浪費。 沒有連接池之前的單一連線機制有什麼問題？ 首先來談談連接池之前的單一連接機制， 在配置正確的狀況下可能不會遇到任何問題， 但假設我們的應用同時間有100個用戶進行查詢， 那麼通道只有一條， 在怎麼樣都得等待前一個人查詢並回傳完畢才能再服務其他人的查詢請求， 一旦請求量越來越高將導致系統開始變慢， 可能會遇到的幾個缺點及風險如下： ● 每秒請求10個查詢可能還沒感覺到明顯延遲， 但假設每秒10000個以上的請求呢？ 勢必降低查詢效率。 ● 我們整個系統都依賴於單一連線， 那麼假設這個連線在例外的狀況下被關閉時， 那麼是不是就無法回應給Client端了？ ● 連接到資料庫是一個成本昂貴的開銷， 因此常常連接關閉， 顯然不是一個有效率的策略。 為了改善上述缺點， 而發展出連接池的概念。 什麼是連接池？ 連接池的機制下， 不僅能應付同時間大量請求的場景， 就連單一連線也能支援。 系統啟動時， 根據連線池數量配置， 創建N個連接並加入到連接池。 圖片來源 配置的數量過大亦會造成浪費， 這點需要取決於我們的應用量的估計。 每次跟DB請求前， 就會先從連接池中取得一條通道跟DB溝通。 圖片來源 當連接池的連線都被用滿的時候， 會等待其他人的連接被釋放。 圖片來源 結語 這樣的概念很聰明，相當於準備了一個緩衝站，而這個緩衝站的資源是共享的，因此對於後者的資料庫來說是一大福音，不會因為各個程式每一個動作就一次連接導致資料庫可以服務的資源耗盡。 其實現在的共享經濟(交通、住宿、場地...)，就有點類似這樣的概念，透過購置有效的資產，開放平台提供給普羅大眾使用，而使用完畢後進行歸還，這樣一來能夠有效減少不必要的浪費，讓使用效率最大化。