Programming Language Notes

圖片來源 區塊(Block) 區塊概念的出現是為了解決傳統大量交易的問題，過往的交易假設同時間有兩筆對帳戶操作的請求發出時，接收端僅能以先來後到的處理方式回絕掉後來的交易，但這樣其實並不公平，因為受限於距離與環境，並不代表第二筆交易是無效的，而且第一筆交易也難辨真偽，而區塊的出現也衍生出共識機制，大部分節點認可這筆交易時才算是成立。 區塊鏈當中相當重要的環節就是塊與塊之間的帳務計算，以及使用者付費的手續費，而這些計算就是在區塊之中的每個不同單位，我們來看以下的圖，描繪出區塊組成的單位與各自用途，我們就想像成RPG遊戲中的角色裝備，各自具有不同用途與加乘效果。 圖片來源 以上的元素不外乎就是在計算每個「區塊」的完成度與費用，畢竟我們使用區塊鏈的資源就像是高速公路一般，使用者付費，只是計算方式有所不同而已，關於gas的計算，我們會在概念篇進行介紹，因此這邊就不加以贅述，以下我們實際用solidity來撰寫一番。 // SPDX-License-Identifier: MIT pragma solidity ^ 0.8 .18 .0 ; contract BlockTransactionInfo { // 獲取當前區塊的區塊數字 function getBlockNumber () public view returns ( uint ) { return block.number; } // 獲取當前區塊的時間戳 function getBlockTimestamp () public view returns ( uint ) { return block.timestamp; } } 交易(Transaction) 在 Solidity 中，交易（Transaction）是指由外部帳戶向智能合約發送的請求，以執行合約中的函式或進行狀態修改。每個交易都包含一些重要的屬性和信息。 以下的例子我們可以「獲取當前交易的發送者地址」與「處理交易的數量」。 // 獲取當前交易的發送者地址 function getTransactionSender () public view returns ( address ) { return msg.s...

  一套大型的智能合約通常都會拆分成許多小合約，並且透過匯入的方式拼裝而成，而這樣的匯入在Solidity世界中就是「Import」，就讓我們來看看「Import」到底怎麼運用吧！ 基本的相對路徑匯入方式 假設目錄結構如下 example.sol other.sol 我們引入的方式就會是： import './other.sol' 也可以遠端匯入 import 'https://example.com/xxx.sol' 彈性的自訂名稱功能 當衝突發生時 當我們使用import時，預設會採用外部模組定義好的方法名稱，但這樣很容易發生衝突，假設外部有一個方法定義為「add()」，但內部也定義成相同名稱的方法時，會發生「DeclarationError」的錯誤，示範如下： external.sol // SPDX-License-Identifier: MIT pragma solidity ^0.8.7.0; function add(uint x, uint y) pure returns (uint) { return x + y; } example.sol // SPDX-License-Identifier: MIT pragma solidity ^0.8.7.0; import {add} from "./external.sol"; contract Example { function add(uint x, uint y) public pure returns (uint) { return x + y; } } 發生的錯誤如下： 如何補救呢？ solidity也跟javascript一樣提供別名的方式，為外部的衝突方法特定一個內部名稱，避免與內部相互衝突，import的方式如下： import {add as extAdd } from "./external.sol"; 結語 這次介紹的import對於模組化非常的有幫助，尤其是分工協作的開發模式下，將需要的模組、功能規劃完畢之後就能夠各自進行開發，並且最終統一彙整，以拼裝積木的方式將各個功能模組兜在一起就能完成一份更加完整的智能合約，也讓合約的內容更加清晰，不會過於複...

  Mapping(映射)就像是字典表一樣，鍵入「什麼樣的標題」對應到「什麼樣的內容」，而標題就是從內容提煉出來的一種簡短快速識別的標的，透過這種方式，我們未來找尋內文時，只要先透過標題來查找，絕對會比直接找內文快上好幾倍，因此Mapping常常應用在查找事物上，它有點像一般程式語言的HashTable，主要目的在於透過對應表快速定位到詳細的資訊。 語法結構 /// 錢包餘額對應表 /// 錢包地址 <-剩餘-> 金額 mapping(address => uint) public _balances; 如何設定對應表？ function updateBalance(uint newBalance) public { _balances[msg.sender] = newBalance; } 取得特定值 取得的方式非常簡單，我們宣告一個正確型別的變數進行承接之後，就能夠使用到儲存的值，進行加工後，再次設定。 uint _balance = _balances[msg.sender]; 刪除某一組 藉由delete關鍵字重新設定某一組key值。 delete _balances[msg.sender]; 相關的限制 - 鍵值(Key)僅能是Solidity的基本型態(strings、uint…)，複雜型態(array、struct…)是不被允許的。 - 預設不支援iterable，因此無法自然的逐一處理，但提供自行實作的擴充能力， 請參考這裡 。 結語 Mapping是一種非常好用的資料結構，我們日常生活中諸如電話黃頁、書籤、五金行分類…等，舉凡與搜尋有關的整理，皆是在將龐雜的資訊濃縮成摘要，並且進行恰當的分類之後，讓我們更容易找尋這堆龐雜的資料，在區塊鏈的世界上亦是如此，錢包地址的背後可能夾藏的非常複雜的資訊，透過Mapping快速定位到關鍵位置，進行進一步的處理。 今天的範例都在這裡「 📦 solidity-remix-toturial/Ep15 」歡迎自行取用。 📚 更多關於Solidity的文章請看這裡… ---------------------------------------------------------------------------------- 喜歡撰寫文章的你，不妨來了解一下： W...

  密碼學能夠帶來什麼好處？ 雲時代的來臨， 我們過往使用的桌面版應用程式逐漸搬上雲端， 但也帶來了極大的挑戰， 因為一但上雲就代表著需要面臨著四面八方的使用者， 我們並不知道這些使用者是否都是君子， 一個不小心如果出現漏洞就可能被攻擊， 導致系統損壞， 進而影響商譽、營收， 對企業來說是極大的傷害， 為了避免這樣的狀況發生， 資安防禦體系下的「密碼學」就扮演著極其重要的角色， 讓伺服器與客戶之間的溝通具有一層嚴格的防護網， 減少過程中被竊取、破壞的風險，伺服器的資料也能藉由「密碼學」獲得重要的保護效果，， 而「密碼學」也是一門博大精深的技術， 接下來的系列將以最簡單的方式講述密碼學的原理， 讓我們在資安意識抬頭的時代能夠增加一門功夫， 以因應時代需求的發展。 密碼學的「雜湊」與「加密」是區塊鏈發展的重要基石 區塊鏈可以拆解為「區塊」跟「鏈」，「區塊」就是一份份的資料帳本，而「鏈」就是由密碼學的Hash原理串起來的，每一個「區塊」中皆存放目前的Hash值與上一個區塊的Hash值，以此環環相扣連結成鏈。 因此我們才要好好的認識編碼、加密與雜湊的差異，避免名詞造成混淆，而後續的篇章也會深入來潭討雜湊函數的奧秘，讓我們對於區塊鏈的運作原理能夠有更進一步的認識。 編碼(Encode)、雜湊(Hash)、加密(Encrypt)究竟有什麼不同？ 「編碼(Encode)」其實離我們很近…，原來電影情節常常出現的「摩斯密碼」成為了最貼切的例子。 相信我們常常看到電影情節中不時就出現「摩斯密碼」的名詞， 而密碼學之中的「編碼」也是類似這樣的概念， 簡單來說就是「資料內容替換成不易閱讀的符號、文字」以獲得保護， 過程中一但資料被擷取也不易閱讀， 是保護門檻中最基本的一項， 但也是最弱的， 因為一但編碼還原表被竊取， 或是使用大家都知道的編碼表， 就很容易進行還原破解。 常見的編碼格式 - URL編碼。 - UTF-8。 - ASCII。 - Unicode。 - Base64。 「雜湊(Hash)」就是碎片化與拼湊的過程 雜湊！雜湊！雜湊！其實並不難理解，簡單來說就是將「大量的資料碎片化之後再拼湊」，因此雜湊出來的結果並不能「逆推」回原文，那這樣帶來什麼好處呢？ 試想，我們碎片化之後再拼湊出來的資訊一定是簡化過的，因此對於容量的佔用，資訊的精準度都具有一定的影響力，不論在搜尋或...

  何謂函式庫？ 簡單的來說就是把同類型常用的功能打包在一起，讓其他開發者能夠重複使用，達到資源有效利用的效果，以軟體開發來說就是減少多餘的程式碼，而Solidity語言中，Library可以視為物件導向中的靜態類別，不需要產生實體就能使用，因此能有效的減少Gas。 當我們剛完成一份合約時難免因為設計尚未考慮周全而導致複雜與重複的邏輯，但當我們回頭看看之後，就會發現有一些冗餘的程式碼可以進行整理，甚至分類到不同的地方，如同撰寫文章的草稿一樣，撰寫完畢後進行檢查，會發現有些區段可以挪移到外部的文章進行嵌入…等，讓一篇文章不至於過多的雜訊，而智能合約之中亦是如此，我們可以將共同複雜的邏輯整理到Library並歸類，之後倘若設計多份合約發現共同邏輯時就能夠引入並使用，非常靈活彈性。 建立一個函式庫來玩玩唄 - 情境： 自己打造一個數學函式，並檢核數值是否為「奇數」。 - 以「library」取代「contract」。 - 不需要有static。 - 不需要進行初始化建構(constructor)。 library Math { function checkOdd(uint value) public pure returns(bool) { uint remainder = value % 2; if(remainder!=0) return true; else return false; } } 如何使用？ 引用別人撰寫好的Library會使用「import」來進行引用，而引用的對象也是一支Solidity撰寫的模組，使用起來也非常的直觀，直接以Library的名稱進行function的調用即可。 // SPDX-License-Identifier: MIT pragma solidity ^0.8.7.0; import "./math.sol"; contract Example { function checkOdd(uint value) public pure returns(bool) { return Math.checkOdd(value); } } 結語 此篇章適合對於Solid...