以太坊怎麼開發

A. 如何基於ethereum開發區塊鏈應用

目前實際動手做區塊鏈開發，大致有兩條路。

直接基於現成的區塊鏈開發平台（主要是Ethereum和HyperLedger）來開發。山茄

自己從基礎開始造區塊鏈，表面上看，從開發效率、投入成本、產業合作等方面毫無疑問應該走第一條路，但搏檔實際上情況要復雜得多。

區塊鏈的發展，還是需要更多寫代碼的人實際參與，才能實實在在的推動。

現在整個技術社區的注意力主要還是在Web和移動開發逗銀察上面，相關人才供銷兩旺。不過個別有心人已經開始轉向大數據分析、深度學習、VR/AI這些前景看好的技術。

B. ETH開發實踐——批量發送交易

在使用同一個地址連續發送交易時，每筆交易往往不可能立即到賬， 當前交易還未到賬的情況下，下一筆交易無論是通過 eth.getTransactionCount() 獲取nonce值來設置，還是由節點自動從區塊中查詢，都會獲得和前一筆交易同樣的nonce值，這時節點就會報錯 Error: replacement transaction underpriced

在構建一筆新的交易時，在交易數據結構中會產生一個nonce值， nonce是當前區塊鏈下，發送者(from地址)發出的交易(成功記錄進區塊的)總數， 再加上1。例如新構建一筆從A發往B的交易，A地址之前的交易次數為10，那麼這筆交易中的nonce則會設置成11， 節點驗證通過後則會放入交易池（txPool）,並向其他節點廣播，該筆交易等待礦工將其打包進新的區塊。

那麼，如果在先構建並發送了一筆從地址A發出的，nonce為11的交易，在該交易未打包進區塊之前， 再次構建一筆從A發出的交易，並將它發送到節點，不管是先通過web3的eth.getTransactionCount(A)獲取到的過往的交易數量，還是由節點自行填寫nonce， 後面的這筆交易的nonce同樣是11， 此時就出現了問題：

實際場景中，會有批量從一個地址發送交易的需求，首先這些操作可能也應該是並行的，我們不會等待一筆交易成功寫入區塊後再發起第二筆交易，那麼此時有什麼好的解決辦法呢？先來看看geth節點中交易池對交易的處理流程

如之前所說，構建一筆交易時如果不手動設置nonce值，geth節點會默認計算發起地址此前最大nonce數（寫入區塊的才算數），然後將其加上1， 然後將這筆交易放入節點交易池中的pending隊列，等到節點將其打包進區塊。

構建交易時，nonce值是可以手動設置的，如果當前的nonce本應該設置成11， 但是我手動設置成了13， 在節點收到這筆交易時， 發現pending隊列中並沒有改地址下nonce為11及12的交易， 就會將這筆nonce為13的交易放入交易池的queued隊列中。只有當前面的nonce補齊（nonce為11及12的交易被發現並放入pending隊列）之後，才會將它放入pending隊列中等待打包。

我們把pending隊列中的交易視為可執行的，因為它們可能被礦工打包進最新的區塊。 而queue隊列因為前面的nonce存在缺失，暫時無法被礦工打包，稱為不可執行交易。

那麼實際開發中，批量從一個地址發送交易時，應該怎麼辦呢？

方案一：那麼在批量從一個地址發送交易時， 可以持久化一個本地的nonce，構建交易時用本地的nonce去累加，逐一填充到後面的交易。（要注意本地的nonce可能會出現偏差，可能需要定期從區塊中重新獲取nonce，更新至本地）。這個方法也有一定的局限性，適合內部地址（即只有這個服務會使用該地址發送交易）。

說到這里還有個坑，許多人認為通過 eth.getTransactionCount(address, "pending") ，第二個參數為 pending ， 就能獲得包含本地交易池pending隊列的nonce值，但是實際情況並不是這樣， 這里的 pending 只包含待放入打包區塊的交易， 假設已寫入交易區塊的數量為20， 又發送了nonce為21，22，23的交易， 通過上面方法取得nonce可能是21（前面的21，22，23均未放入待打包區塊）， 也可能是22（前面的21放入待打包區塊了，但是22，23還未放入）。

方案二是每次構建交易時，從geth節點的pending隊列取到最後一筆可執行交易的nonce, 在此基礎上加1，再發送給節點。可以通過 txpool.content 或 txpool.inspect 來獲得交易池列表，裡面可以看到pending及queue的交易列表。

啟動節點時，是可以設置交易池中的每個地址的pending隊列的容量上限，queue隊列的上容量上限， 以及整個交易池的pending隊列和queue隊列的容量上限。所以高並發的批量交易中，需要增加節點的交易池容量。

當然，除了擴大交易池，控制發送頻率，更要設置合理的交易手續費，eth上交易寫入區塊的速度取決於手續費及eth網路的擁堵狀況，發送每筆交易時，設置合理的礦工費用，避免大量的交易積壓在交易池。

C. EOS的開發流程

EOS的是Block.One主導研發的一個區塊鏈底層公鏈系統，它專門為支撐商業去中心化 應用（Decentralized Application）而設計，其代碼開源。

比特幣被稱為區塊鏈1.0，因為它開辟了數字加密貨幣的天下，走出了從0到1的決定性一步。

以太坊被稱為區塊鏈2.0，因為它提供了可運行智能合約的圖靈完備的虛擬機，帶來了無限的可能性。

而EOS則被稱為區塊鏈3.0，為什麼？ 兩個字：性能。

EOS的定位正是其首頁的口號：

英文：The most powerful infrastructure for decentralized applications。

中文：最強大的去中心化應用基礎設施。

EOS期望做加強版的以太坊，一個高吞吐量的智能合約平台。

以太坊雖然功能齊備，但受制於其設計選擇，15秒的出塊速度導致交易吞吐量 遠遠不能達到大規模實用的程度，大約只有30~40TPS（交易/秒）。而EOS則選擇了不同的技術路線，目標是達到可觀的百萬TPS——考慮到Visa實際的處理速度才1700TPS，這一目標的確相當誘人。

EOS的共識機制

比特幣和以太坊之所以吞吐量這么低，是受制於其設想的應用場景以及針對該場景所選擇的共識機制——這兩者都假設系統運行的環境完全不可信，因此都採用了工作量證明（Proof of Work）這種共識機制。

共識，顧名思義，就是大家對某件事達成統一的認識——對於 區塊鏈而言，某件事指的就是對交易的確認——任何一個節點要提交交易，都需要大家認可。

比特幣和以太坊目前所採用的PoW機制是傳奇人物中本聰的設計。在這種機制下，礦工們為了獲得記賬權和數字幣獎勵，需要不停挖礦來尋找合規的哈希值，通過對哈希值的共識來對交易數據進行確認和打包。PoW沒有準入門檻，任何節點都 有平等的權利參與記賬——當然，勝出的概率與算力有關：

RAM的價格是基於班科（Bancor）演算法，也就是說是由市場供需調節的：如果RAM供不應求，則買入RAM時就需要更多的EOS通證，而這時賣出RAM也能獲得更多的EOS通證。

內存是消耗資源，不可贖回，只能買賣。以EOS上發幣為例，目前發幣需要20M的內存，一個EOS可買20KB，按目前的存儲價格發一個幣需要消耗1000個EOS。這是EOS內存消耗的剛需來源。

課程概述

本課程面向對EOS去中心化應用開發感興趣的朋友，課程內容涵蓋EOS DApp開發的核心概念、智能合約的開發與部署以及前端頁面與EOS區塊鏈如何交互，並最終完成一個基於React和EOS的完整Dapp的開發。

第一章：進入EOS世界

了解EOS的定位與特點、共識機制、付費計算模型等核心概念。

第二章：Hi EOS

了解EOS節點的軟體整體框架以及節點伺服器、錢包伺服器和命令行工具的作用， 學習配置、啟動EOS節點伺服器和錢包伺服器的方法，初步了解命令行工具的使用方法。

第三章：錢包、密鑰與賬戶

理解EOS中與個人身份相關的三個核心概念：錢包、密鑰與賬戶，學習使用命令行工具 創建錢包、密鑰與賬戶的方法。

第四章：智能合約的開發與交互

了解智能合約的概念與作用，學習EOS智能合約的編寫和編譯，學習使用命令行工具 部署合約並與合約交互。

了解EOS智能合約中狀態的持久化機制，學習使用多索引表保存合約狀態。

第五章：發行自己的代幣

學習在EOS上發行代幣的原理和實現機制，並通過實際操作，掌握如何 使用命令行工具進行代幣的發行、轉賬和余額查看等操作。

第六章：使用代碼與智能合約交互

理解應用與EOS區塊鏈交互的原理，學習利用JSON RPC介面和eosjs封裝庫來 訪問EOS區塊鏈。

第七章：實戰便簽DApp開發

綜合運用EOS知識，使用React完成一個EOS便簽去中心化應用，學習從需求分析到 代碼實現的完整過程。

eos開發還是需要一個完整的學習的，上面的課程地址如下：EOS教程

D. 以太坊是什麼，誰創建的

以太坊（英文Ethereum）是一個開源的有智能合約功能的公共區塊鏈平台，通過其專用加密貨幣以太幣（Ether）提供去中心化的虛擬機（「以太虛擬機」 Ethereum Virtual Machine）來處理點對點合約。
以太坊的概念首次在2013至2014年間由程序員Vitalik Buterin受比特幣啟發後提出，大意為「下一代加密貨幣與去中心化應用平台」，在2014年通過ICO眾籌開始得以發展。
截至2018年2月，以太幣是市值第二高的加密貨幣，僅次於比特幣。

E. 如何開發數字貨幣

謝邀~

為何要開發數字貨幣?從中央銀行的角度來看有6個好處：

第一、提升經濟交易活動的便利性和透明度

第二、降低傳統紙幣發行、流通的高昂成本

第三、更好地支持經濟和社會發展

第四、助力普惠金融的全面實現

第五、 減少洗錢、逃漏稅等違法犯罪行為

第六、提升央行對貨幣供給和貨幣流通的控制力

數字貨幣開發步驟：

第一步、

首先我們要從git 上下載某套區塊鏈體系的源碼,比如選擇比特幣的主幹代碼下載好

相關源碼。

同時准備好對應的編譯環境(C + +的建議在Linux)和安裝好對應開發環境和工具。

第二步、

代碼都是需要編譯的,因此需要准備編譯環境和工具,需要下載環境編譯工具、配

好系統環境變數, qt環境等文件,編譯命令在Itc源代碼里的文件里有詳細說明。

不過系統和開發環境的搭建、程序編譯等過程都比較繁瑣,不建議普通用戶自己製作。對於開發人員,第一次可能要預計2-3天的安裝配置時間。

第三步、

拿比特幣開發來說,他是Q的開發環境，下載好源碼並配置好環境後,在QtCreator內打開該比特幣核心的源碼,配置相關文件和編譯器,開始嘗試編譯比特幣核心的客戶端。

第四步、

改造成自己的數字貨幣，打開各個源文件,找到對應的地方調整參數即可,如調整

每個區塊出幣數,總產量,調整難度等等,然後就到最關鍵的點,就是改名為自己的幣名。

想怎麼取名就怎麼取名,別忘記在資源文件夾里替換掉相關圖標。如果一切順利,經過重新

編譯,你的新幣就順利發明了。

對於這個數字貨幣的開發,還是屬於技術比較專業的,因此最好有-個專業的團隊協助。

數字貨幣開發大致需要學習的框架：

1、搭建以太坊私鏈測試環境以及公鏈節點環境配置

2、以太坊中以太幣的交易、確認原理

3、以太坊中json rpc介面

4、以太幣轉賬與提現原理

5、伺服器對接以太坊公鏈介面，自有伺服器存儲業務數據，公鏈存儲交易可匿名數據

6、私鑰的安全處理

以下是開發的代碼示例：

舉例下市場上常用的數字貨幣錢包有：

APP類：kcash、imtokenweb：myEthereumWalletgoogle 瀏覽器插件：metaMask

其中最常用的就是imToken

區塊鏈交易技術概念：

讓我們來看看區塊鏈交易是如何以比特幣為例進行處理的。為了將一定數量的比特幣發送到另一個錢包，您需要以下信息：將資金發送到您的錢包的地址，您想要發送的加密貨幣數量

接收者的錢包的ID。

每筆交易都使用唯一的機密私人密鑰進行簽名。一旦付款由發件人簽署，它就變為公開可用。交易仍需要確認，以便收款人可以得到這筆錢為了確認交易，有必要生成一個新的鏈條塊。

這些塊是通過進行復雜的數學計算來找到唯一的密鑰而生成的。創建一個新塊需要10分鍾，找到該密鑰的人獲得一定數量的硬幣作為獎勵。一旦創建了鏈的新塊，就不可能將其從資料庫中刪除或以某種方式更改信息。因此，區塊鏈交易是最終且不可逆的。

數字貨幣的三大核心優點：

第一點、數字貨幣是公平的貨幣

數字貨幣沒有特定的發行機構，不是由某一國家發行的，僅僅是依靠特定演算法產生的，這就意味著無法通過操縱發行數量來操縱數字貨幣，因此數字貨幣是一種自由的、非國家的貨幣。

我們可以看到現在有許多國家是直接認可了虛擬貨幣，那麼有需求，就需要交易的平台。

我們現在許多想搭建虛擬貨幣交易平台的投資者，為什麼不能去這些地區搭建交易平台呢?搭建虛擬貨幣交易平台，這不就是一個很好的商機嗎?

第二點、數字貨幣的安全系數更高

紙幣的出現雖然方便了我們日常生活中的交易，但是會有被偷盜以及收到的風險。電子貨幣雖然可以避免這些風險，但是會出現諸如被盜刷、等新的問題。

數字貨幣則可以避免以上問題。並且將每一筆交易記錄在網路上進行廣播，是的所有節點都保存全部貨幣的流通信息，這樣任意一個節點在交易之前就可以輕易地發現貨幣的流通。

第三點、數字貨幣的交易可以實現匿名交易

由於沒有傳統銀行開戶和身份認證的過程，數字貨幣是純匿名的。雖然可以根據本地完整的交易記錄查詢到每個賬號的流水信息。

但卻無法知道這個賬號的主人是誰，同樣也沒有任何人有能力操縱他人賬號上的數字貨幣，這樣很好的保護了使用人的隱私。

如果您也在持有交易數字貨幣、外匯黃金原油、合約期貨：

F. 區塊鏈和智能合約，以太坊開發，183位開發者整理，知識體系匯總

在以太坊上開發應用程序的可用工具、組件、模式和平台的指南。

此列表的創建是由 ConsenSys 的產品經理推動的，他們認為需要在新的和有經驗的區塊鏈開發人員之間更好地共享工具、開發模式和組件。

開發智能合約

智能合約語言

構架

IDE

其他工具

測試區塊鏈網路

測試以太水龍頭

前端以太坊 API

後端以太坊 API

引導程序/開箱即用工具

以太坊 ABI（應用程序二進制介面）工具

以太坊客戶端

貯存

Mahuta - 具有附加搜索功能的 IPFS 存儲服務，以前稱為 IPFS-Store

OrbitDB - IPFS 之上的去中心化資料庫

JS IPFS API - IPFS HTTP API 的客戶端庫，用 JavaScript 實現

TEMPORAL - 易於使用的 API 到 IPFS 和其他分布式/去中心化存儲協議

PINATA - 使用 IPFS 的最簡單方法

消息傳遞

測試工具

安全工具

監控

其他雜項工具

Cheshire - CryptoKitties API 和智能合約的本地沙箱實現，可作為 Truffle Box 使用

ERCs-以太坊評論請求存儲庫

ERC-20 - 可替代資產的原始令牌合約

ERC-721 - 不可替代資產的令牌標准

ERC-777 - 可替代資產的改進令牌標准

ERC-918 - 可開采令牌標准

流行的智能合約庫

可擴展性

支付/狀態通道

等離子體

側鏈

POA橋

POA 橋用戶界面

POA 橋梁合同

ZK-SNARK

ZK-STARK

預構建的 UI 組件

以上內容，來自git庫：

github.com/ConsenSys/ethereum-developer-tools-list

我是魚歌，一個在深圳創業的全棧程序員，主攻區塊鏈，元宇宙和智能合約，附加小程序和app開發。

[祈禱]

G. 想在以太坊上發個幣但不會寫代碼，這時該怎麼發幣

首先我可以很明確的告訴你：如果你本人不會寫代碼，並且不懂虛擬貨幣的發行方式，沒有任何人可以教你，網上也沒有相關的教程，因為虛擬貨幣的發售本身就屬於違法行為。

其次，我也知道你在以太坊上發幣是什麼用途，無非就是做一個資金盤騙人罷了，奉勸你遵紀守法！因為公民發售虛擬貨幣做資金盤是嚴重的違法行為！

以太坊上面確實可以發行自己的虛擬貨幣。

不知道是不是最近的虛擬貨幣牛市把有些人炒傻了，還是有些人本身就是屬於歪門邪道的人，竟然會在網上提問怎麼在乙太網上發售虛擬貨幣？我在看到這個問題的時候非常無語：一個想要做騙子的人竟然問別人怎麼樣實行自己的騙術，簡直可笑。以太坊確實可以發售虛擬貨幣，但如果你連基本的發售虛擬貨幣的方式都不懂，你又怎麼樣談你在以太坊上面的項目。

H. 以太坊是騙人的嗎怎麼做

以太坊並非騙局，但是不法分子圍繞著以太坊設計的騙局數不勝數，規避以太坊騙局的最好方式就是，切莫輕信比人保證的投資收益率，管理好自己的錢袋子。選擇正規的數字貨幣交易所，去做投資。目前市場上主流的數字貨幣交易所有幣安、火幣網、比特網等。

拓展資料
以太坊設計原則
簡潔原則
以太坊協議將盡可能簡單，即便以某些數據存儲和時間上的低效為代價。一個普通的程序員也能夠完美地去實現完整的開發說明。這將最終有助於降低任何特殊個人或精英團體可能對協議的影響並且推進以太坊作為對所有人開放的協議的應用前景。添加復雜性的優化將不會被接受，除非它們提供了非常根本性的益處。
通用原則
沒有「特性」是以太坊設計哲學中的一個根本性部分。取而代之的是，以太坊提供了一個內部的圖靈完備的腳本語言以供用戶來構建任何可以精確定義的智能合約或交易類型。想建立一個全規模的守護程序（Daemon）或天網（Skynet），你可能需要幾千個聯鎖合約並且確定慷慨地喂養它們，一切皆有可能。
模塊化原則
以太坊的不同部分應被設計為盡可能模塊化的和可分的。開發過程中，應該能夠容易地讓在協議某處做一個小改動的同時應用層卻可以不加改動地繼續正常運行。以太坊開發應該最大程度地做好這些事情以助益於整個加密貨幣生態系統，而不僅是自身。
無歧視原則
協議不應主動地試圖限制或阻礙特定的類目或用法，協議中的所有監管機制都應被設計為直接監管危害，不應試圖反對特定的不受歡迎的應用。人們甚至可以在以太坊之上運行一個無限循環腳本，只要他願意為其支付按計算步驟計算的交易費用。

I. 以太坊智能合約開發：讓合約接受轉賬

在以太坊智能合約開發中，通常會有向合約地址進行轉賬的需求，那麼有幾種向合約地址進行轉賬的方式呢？

有三種方式：

部署合約時轉賬

調用合約提供的方法

直接向合約地址進行轉賬

但有一個問題，以太坊的智能合約默認是拒絕來自任何地址的轉賬，那麼如何讓合約能夠支持接收轉賬呢？

1、部署轉賬

在進行合約開發時，如果想要在部署時，直接向該合約進行轉賬，只需要給構造函數中添加payable修飾符。

示例：

2、執行合約轉賬

執行合約轉賬，則需要給你需要支持轉賬功能的方法添加payable修飾符

示例：

3、直接轉賬

支持直接轉賬，需要藉助後備函數(fallback function)，只需要為後備函數添加 payable 修飾符

示例：

J. ETH開發實踐——合約地址是怎麼得來的

在把智能合約成功部署到ETH網路時，會得到合約地址，那麼，這個合約地址是由什麼決定的呢？合約地址由合約創建者的地址(sender address)和這筆部署交易中的nonce(發送者的累積交易次數)決定，將 sender 和 nonce 經過RLP編碼後，再進行Keccak-256(SHA3)散列， 最後裁掉前面12個位元組即得到合約地址。

example in js: