什麼時候將節點伺服器用於使用智能合約的應用程序？
我想知道是否存在使用典型 Node.js 客戶端-伺服器應用程序的範例案例，其中區塊鏈節點將在伺服器上執行。乍一看，如果是伺服器本身執行節點，這將帶回與信任伺服器相關的集中化問題。但是，我想知道是否存在合適的真實案例（這裡有一些似乎正在這樣做的人的問題 -例如this，this）。
進一步澄清：我閱讀了這篇文章，聲稱尚未收集到 Dapp 開發所需的工具。因此，我想知道仍然可以利用區塊鏈的可靠性等特性但在客戶端-伺服器框架中執行的替代方案。
我認為@JohnAllen 的回答對我來說沒有意義。最常見的做法就是將 DApp 的前端 UI 實現為 NodeJS 應用程序，該應用程序使用 Web3 Javascript 庫與本地執行的乙太坊節點進行通信，即與 NodeJS 應用程序在同一台伺服器上。
在這裡，NodeJS 伺服器本身並不執行乙太坊節點。（注意區分此處“節點”一詞的兩種用法）乙太坊節點（可以是 geth、Parity、pyethapp 或任何其他乙太坊客戶端軟體）和 NodeJS 應用程序都在同一台機器上執行。乙太坊節點是與之同步的乙太坊區塊鏈的客戶端。實際上，NodeJS 應用程序與本地執行的乙太坊節點通信減少了集中化，因為不同的應用程序不需要信任任何特定的遠端乙太坊節點。此外，帳戶始終在本地節點上創建，因為生成的私鑰應保留在本地電腦上。創建和管理帳戶的命令位於
web3.eth.personal預設情況下，該介面僅通過 IPC（程序間通信）啟用，即只能在本地乙太坊節點上執行。補充： 如果 DApp 的前端介面由執行在特定伺服器上的 NodeJS 應用程序提供服務，它會引入一些集中化。但是，只要 DApp 仍然可以保持其模型的狀態（使用 MVC 意義上的“模型”），即使 NodeJS 伺服器出現故障，並且如果其他人可以託管 NodeJS 應用程序從而恢復 MVC 的“視圖”和提供對後端的訪問（部署在區塊鏈上的合約程式碼），然後將中心化的缺點降到最低。所以，我的觀點是集中化/分散化不是非黑即白的分類。任何應用程序都在某個範圍內。一個 DApp可以它的 UI 也以分散的方式提供服務，例如，我聽說過 Swarm 和 IPFS 對此提出了建議，但我不知道如何做到這一點的更多細節。這完全取決於具體情況以及真正需要多少去中心化。
這對我來說大多沒有意義，原因如下：
區塊鏈節點將在伺服器上執行的位置
a 的定義
blockchain node是儲存區塊鏈數據並經常響應有關該數據的請求的數以千計的乙太坊節點之一。因此，當您擁有一個帶有伺服器和客戶端的架構時
Ethereum node——Node.jsNode.js伺服器會做什麼？通常
Node.js用於響應伺服器端請求、執行邏輯和查詢集中式數據庫；但是對於 Dapps，區塊鍊和web3（這是一個伺服器或客戶端庫）查詢區塊鏈數據，乙太坊節點以請求的數據響應，然後將其返回給客戶端。
Node.js您在評論中提到儲存數據。另一種選擇是以集中方式或 IPFS 儲存數據。您可以將簡單的雜湊或 CID（內容標識符）儲存在鏈上，並將雜湊指向的數據儲存在集中式數據庫中，查詢儲存在鏈上的雜湊（內容編碼在雜湊中），查詢您的數據通過雜湊，對查詢的數據執行相同的雜湊函式以驗證它是否相同，然後將該數據返回給您的客戶端。