---
tags: Blockchain
---

# Dapp 架構探討
contributed by < [steven1lung](https://github.com/steven1lung) >

## Dapp 所要具備的條件
1. 不能控制使用者的 private key
2. 不能幫助使用者簽署 transaction 合約
3. 重要的資料跟程式碼都要在區塊鏈上
4. 智能合約上要有資安工具在執行
5. Dapp 要先在 public testnet 測試過
6. 使用以太位址來區分使用者
7. 對更新的智能合約作出解釋給使用者
8. 解釋 external 資料如何收集的
9. 在 etherscan 上確認你寫的智能合約
10. transaction 在 mining 要給使用者回饋

## 先介紹 Dapp 需要的元素

1. Smart Contract
Dapp 的核心，有價值的資料或是資料的處理都是處存在區塊鏈上。

2. Wallet
儲存使用者 private key 的地方，傳送 transaction 到智能合約。

3. Frontend
一個 UI 介面，讓使用者可以簡單地跟智能合約互動。

4. Backend
這個可有可無，多後端服務可以處理更複雜的操作或是省 gas。

### Pure Dapp

#### 架構：

整個 Dapp 就是去中心化，不用太擔心會被駭客攻擊，資料都是在 IPFS 上。完全沒有中心化儲存，所以採用 'pure' 這個字。

但是目前市面上有這種架構的 Dapp 非常少，原因是因為對於 IPFS 資料庫的存取非常複雜。
> 但是未來一定會有越多 Dapp 採用這種架構

### Common Dapp

#### 架構：

大多的 Dapp 都採用這個架構，由前端直接跟智能合約互動，前端也連接著一個中心化的後端伺服器。

### Backend + Transcaction Broadcast

#### 架構：

這裡跟上面的 common Dapp 不同的地方是在使用者不會在前端直接跟知能合約互動，反而會將 transaction 送到後端，再由後端使用智能合約跟區塊鏈互動。後端會負則確認 transaction 是合法且正確的，才會 broadcast 到乙太網路。

會使用這個架構的原因是保護使用者，使用者可能會發出一些不對的 transaction 或是使用者可能不小心發出 transaction。透過後端確認過 transaction 可以防止這些事情分生。

但是缺點就是整個 Dapp 就沒有那麼去心化，後端伺服器就有可能會是整個 Dapp 的 vulnerability。

### Backend + Signature

#### 架構：

這個架構跟上方的 broadcast 架構一樣，不同的地方在於使用者不會直接在前端建立 transaction，而是會在前端建立一個 「簽章」 (signature)，描述想對智能合約做的動作，簽名後就把整個簽章送到後端。

後端接到簽章後，會先確認簽章內容，從後端建立一個 transaction 並且附上前端傳過來的使用者簽章，一併交給智能合約。

智能合約就會確認 transaction 是從後端送來的，並且確認使用者的簽章是合法的（防止後端偽造使用者發出 transaction）。

好處是使用者不需要付出 gas，因為 transaction 都是從後端的 wallet 發的

問題是後端的伺服器也會是被攻擊的點，如果後端被有心人士利用，是可以將 Dapp 裡目前的 transaction 清空。但是因為智能合約會檢查送來 transaction 的使用者簽章，所以不用擔心駭客會偽裝使用者發出 transction，相對上方的架構安全。

### Backend + centralized wallet

#### 架構：

這個架構的前端不會有 wallet，使用者會跟一般的 web application 一樣跟後端溝通，如果要跟區塊鏈互動，就會透過後端的 wallet 跟區塊鏈互動。

問題在於這個 Dapp 就沒有那麼去中心化，使用者不能參與跟智能合約溝通的部分，是完全由後端負責的。如果 Dapp 想要關掉你的帳戶，那你也沒辦法拒絕。

##### refer
[EatTheBlocks](https://www.youtube.com/watch?v=JUXeIIhOxpE&list=PLbbtODcOYIoFAQPcXQ-O84sMkuk780gP_&index=1&ab_channel=EatTheBlocks)