Solidity
含有「Solidity」共 39 篇內容
全部內容
發佈日期由新至舊
付費限定
DApp就是「去中心化應用」，Ｄ為Decentralization，App為Application。一般的App是屬於中心化應用，也就是說App的所有資料都會在伺服器中。DApp會將關鍵的資料保存在區塊鏈的「分布式帳本」中，並將規則與動作寫成「智能合約」。如：以太坊輕錢包。以太坊輕錢包提供帳戶位址與
Soildity是一種風格類似JavaScript的強型別高階語言，專門用來進行智能合約的開發及編程。本文敘述solidity的獨特之處。
一套大型的智能合約通常都會拆分成許多小合約，並且透過匯入的方式拼裝而成，而這樣的匯入在Solidity世界中就是「Import」，就讓我們來看看「Import」到底怎麼運用吧！
假設目錄結構如下
example.sol
other.sol
我們引入的方式就會是：
import ‘./other.so
Mapping(映射)就像是字典表一樣，鍵入「什麼樣的標題」對應到「什麼樣的內容」，而標題就是從內容提煉出來的一種簡短快速識別的標的，透過這種方式，我們未來找尋內文時，只要先透過標題來查找，絕對會比直接找內文快上好幾倍，因此Mapping常常應用在查找事物上，它有點像一般程式語言的HashTable
我們在前幾篇有介紹到介面的用途，都知道介面可以制定規格，建議可以先複習一下這一篇「【開發智能合約 — Solidity系列】實作篇Ep.10 — 標準化的介面(Interfaces)」，而這次來介紹一個非常抽象的概念，名為「抽象化合約」，果然如其名！ 不太容易理解，這種合約跟介面非常相似，都可以用來
我們上一篇有介紹了「【開發智能合約 — Solidity系列】實作篇Ep.11 — 繼承同源但不同意圖的函數覆寫(Function Overriding)」學習到overriding這個關鍵字的概念，而今天介紹另一個非常相似的名詞overloading(超載)，兩者看似很像，但本質上卻存在著非常大的
讚耶, 剛好在找override的用法, 感謝分享
我們在「【開發智能合約 — Solidity系列】實作篇Ep.9 — 何謂繼承(Inheritance)」有提到繼承的一些基本概念，然而在繼承的過程中我們可能會用到上游的方法，甚至加工，而方法名稱重複了，是否能被允許呢？ 答案是「允許」的，就好比我們雖然繼承了父親的「處事技巧」，但在求新求變的時代中
Interface我們就將之想像成是一種標準化的規範，在產品還沒開發出來之前，我們心中想必已經有個藍圖，嗯…，這個功能需要什麼樣的功能，這時候就可以來制定介面，以「設計」為出發點而後再進入「實作」，如此一來我們在設計階段就能發現一些盲點，減少經過實作過程才發現的窘境，節省繁複修改的成本，而且介面定義
一個功能越趨完善且複雜的合約，勢必會拆成許多合約共同組成，而其實這些組成的合約之中許多的方法、元素都是重複的，因此我們可以使用Inheritance(繼承)的技巧，將共同的屬性、方法抽到某個上級合約，而其餘的合約只要繼承自上級合約，就能減少重複開發的狀況，我們都知道軟體開發的過程，只要開發的原始碼越
Solidity支援兩種特殊的函數，分別是Fallback以及Receive，一個是處理合約中不存在的功能時進行的回退機制，而另一個Receive則是負責收款後的動作，但兩者稱為特殊函數的原因主要是跟我們一般函數不同的地方於它們是屬於匿名的函數，也就是不用給定Function名稱，因此才會較為特殊，
