Tiền sử giao thức Ethereum: Thức tỉnh dần từ cõi Niết Bàn
Tuyển chọn TechFlowTuyển chọn TechFlow
Tiền sử giao thức Ethereum: Thức tỉnh dần từ cõi Niết Bàn
Bài viết này nhằm mục đích điểm lại quá trình phát triển của giao thức Ethereum từ khi bắt đầu cho đến khi ra mắt.
Chuyên sâu báo cáo Web3Bài viết được viết vào ngày 14 tháng 9 năm 2017
Lời người biên soạn: Bài viết này là hồi ký của Vitalik về quá trình phát triển giao thức Ethereum, kể lại hành trình từ ý tưởng ban đầu đến lần phát hành và các đợt cập nhật tiếp theo.
Mặc dù những ý tưởng cốt lõi đằng sau giao thức Ethereum hiện tại đã cơ bản ổn định trong hai năm trở lại đây, hình hài đầy đủ và khái niệm hoàn chỉnh của Ethereum không phải hình thành trong một sớm một chiều. Sau khi blockchain Ethereum ra đời, giao thức của nó đã trải qua một loạt biến đổi và quyết định trọng đại.
Bài viết này nhằm mục đích nhìn lại quá trình tiến hóa của giao thức Ethereum từ khởi nguyên đến thời điểm phát hành. Các công việc khổng lồ do Geth, cppethereum, pyethereum và EthereumJ thực hiện trong quá trình triển khai giao thức, cũng như lịch sử ứng dụng và thương mại hóa hệ sinh thái Ethereum, sẽ không nằm trong phạm vi thảo luận ở đây.
Tương tự, lịch sử nghiên cứu Casper và phân mảnh (sharding) cũng sẽ không được đề cập. Không thể nghi ngờ rằng chúng ta có thể viết thêm nhiều bài nữa để nói về những ý tưởng khác nhau mà Vlad, Gavin, tôi và những người khác từng đưa ra rồi lại từ bỏ — bao gồm bằng chứng POW, chuỗi đa vòng (round-robin multi-chain), siêu lập phương (hypercube), chuỗi bóng (shadow chain - tiền thân của Plasma), chuỗi sợi (chain fibers), các phiên bản khác nhau của Casper, cùng với những suy nghĩ nhanh chóng thay đổi của Vlad về cách lý giải động lực và đặc tính của các bên tham gia trong giao thức đồng thuận. Những câu chuyện đằng sau những ý tưởng này vốn dĩ đã phức tạp đến mức xứng đáng được viết thành một bài riêng. Vì vậy, tạm thời chúng ta sẽ không bàn tới.
Hãy bắt đầu từ phiên bản đầu tiên nhất. Phiên bản này cuối cùng đã trở thành Ethereum, nhưng lúc đó thậm chí còn chưa mang tên Ethereum. Vào tháng 10 năm 2013, khi tôi thăm Israel, tôi dành rất nhiều thời gian với nhóm Mastercoin, thậm chí còn đề xuất họ thêm một số chức năng nhất định. Sau khi suy ngẫm kỹ về những gì họ đang làm, tôi đã gửi cho nhóm một đề xuất, đề nghị mở rộng giao thức của họ để hỗ trợ nhiều loại hợp đồng hơn mà không cần bổ sung một bộ tính năng lớn và phức tạp:
https://web.archive.org/web/20150627031414/http://vbuterin.com/ultimatescripting.html
Cần lưu ý rằng phiên bản này hoàn toàn khác biệt so với tầm nhìn rộng lớn hơn về Ethereum sau này: nó chỉ tập trung thuần túy vào lĩnh vực công nghệ mà Mastercoin đang cố gắng phá vỡ — cụ thể là các hợp đồng hai bên. Trong hợp đồng này, bên A và B cùng góp tiền, sau đó cả hai bên có thể rút tiền dựa trên một công thức nhất định được quy định trong hợp đồng (ví dụ, cược "nếu X xảy ra thì toàn bộ tiền thuộc về A; ngược lại thì thuộc về B"). Ngôn ngữ kịch bản thực hiện hợp đồng này không phải là Turing-complete.
Nhóm Mastercoin ấn tượng với đề xuất này, nhưng họ không muốn từ bỏ tất cả những gì họ đang làm để theo hướng này, trong khi tôi ngày càng tin chắc đây là lựa chọn đúng đắn. Do đó, khoảng tháng 12, phiên bản thứ hai ra đời:
https://web.archive.org/web/20131219030753/http://vitalik.ca/ethereum.html
Ở phiên bản này, bạn có thể thấy kết quả của quá trình tái cấu trúc lớn. Phần lớn ý tưởng này nảy ra trong một chuyến đi bộ dài ở San Francisco vào tháng 11. Đến lúc đó, tôi nhận ra rằng hợp đồng thông minh có tiềm năng hoàn toàn tổng quát. Thay vì ngôn ngữ kịch bản chỉ đơn giản mô tả mối quan hệ giữa hai bên, bản thân hợp đồng giờ đây là một tài khoản hoàn chỉnh, có khả năng sở hữu, gửi và nhận tài sản, thậm chí duy trì bộ nhớ vĩnh viễn (lúc đó gọi là "bộ nhớ", và "bộ nhớ" tạm thời duy nhất là 256 thanh ghi). Ngôn ngữ chuyển từ máy ảo dựa trên ngăn xếp sang máy ảo dựa trên thanh ghi theo ý tôi. Tôi gần như không phản đối điều này, ngoại trừ việc nó dường như phức tạp hơn.
"Ether" theo nghĩa đen là ether (tức nhiên liệu, tương đương gas). Sau mỗi bước tính toán, số dư của hợp đồng được gọi bởi giao dịch sẽ giảm một chút. Nếu hợp đồng hết tiền, quá trình thực thi sẽ dừng lại. Lưu ý rằng cơ chế người nhận thanh toán này có nghĩa là chính hợp đồng phải yêu cầu người gửi trả phí cho nó. Nếu khoản phí này không được gửi đến, thực thi sẽ lập tức bị hủy. Phiên bản giao thức này cấp hạn mức 16 bước thực thi miễn phí, cho phép hợp đồng từ chối các giao dịch không trả phí.
Cho đến thời điểm này, giao thức Ethereum vẫn hoàn toàn do một mình tôi xây dựng. Tuy nhiên, từ đây trở đi, những người mới bắt đầu tham gia. Cho đến nay, người đóng góp nổi bật nhất về mặt giao thức là Gavin, người bắt đầu liên hệ với tôi qua tin nhắn riêng trên about.me vào tháng 12 năm 2013.
Jeffrey Wilcke, nhà phát triển chính của client Go (lúc đó gọi là "ethereal"), cũng liên hệ với tôi và bắt đầu lập trình vào cùng thời điểm. Mặc dù đóng góp của anh ấy chủ yếu tập trung vào phát triển client chứ không phải nghiên cứu giao thức.
Đóng góp ban đầu của Gavin gồm hai phần. Thứ nhất, bạn có thể nhận thấy mô hình gọi hợp đồng trong thiết kế ban đầu là bất đồng bộ: mặc dù hợp đồng A có thể tạo một giao dịch nội bộ cho hợp đồng B ("giao dịch nội bộ" là thuật ngữ chuyên môn của Ethereum: ban đầu chúng chỉ được gọi là "giao dịch", sau đó là "gọi tin nhắn" hoặc "gọi"). Việc thực thi giao dịch nội bộ sẽ không bắt đầu cho đến khi việc thực thi giao dịch đầu tiên hoàn tất hoàn toàn. Điều này có nghĩa là giao dịch không thể dùng giao dịch nội bộ để lấy thông tin từ hợp đồng khác; để lấy thông tin từ hợp đồng khác, chỉ có thể dùng mã vận hành EXTRO (giống như SLOAD dùng để đọc bộ nhớ của hợp đồng khác), nhưng mã này sau đó đã bị loại bỏ dưới sự ủng hộ của Gavin và những người khác.
Khi triển khai đặc tả ban đầu của tôi, Gavin một cách tự nhiên đã triển khai chức năng giao dịch nội bộ một cách đồng bộ, thậm chí không nhận ra sự khác biệt về ý định — nghĩa là, trong cách triển khai của Gavin, khi một hợp đồng gọi hợp đồng khác, giao dịch nội bộ được thực thi ngay lập tức. Khi thực thi xong, máy ảo sẽ quay lại hợp đồng khởi tạo giao dịch nội bộ và tiếp tục thực thi mã vận hành tiếp theo. Với cả hai chúng tôi, phương pháp này dường như vượt trội hơn, vì vậy chúng tôi quyết định đưa nó vào đặc tả.
Thứ hai, một cuộc thảo luận giữa tôi và Gavin (diễn ra trong một buổi đi bộ ở San Francisco, do đó chi tiết chính xác sẽ mãi mất hút trong dòng chảy lịch sử, nhưng có thể tồn tại trong một vài bản sao sâu trong kho lưu trữ NSA) đã dẫn đến việc tái cấu trúc mô hình phí giao dịch, chuyển từ cách thanh toán của hợp đồng sang cách thanh toán của người gửi, và chuyển sang kiến trúc nhiên liệu. Thay vì tiêu thụ một lượng ether nhất định sau mỗi bước tính toán độc lập, trong phiên bản này, người khởi tạo giao dịch sẽ trả một khoản phí nhất định và được cấp một lượng nhiên liệu nhất định (gần như là bộ đếm các bước tính toán). Đồng thời, các bước tính toán phụ thuộc vào giới hạn nhiên liệu. Nếu một giao dịch tiêu thụ hết nhiên liệu, nhiên liệu đó sẽ bị mất, nhưng toàn bộ quá trình thực thi sẽ được hoàn tác. Đây dường như là cách an toàn nhất, vì nó loại bỏ mọi kiểu tấn công thực thi từng phần mà hợp đồng trước đây phải lo ngại. Khi giao dịch hoàn tất, bất kỳ khoản phí nào tương ứng với nhiên liệu chưa dùng sẽ được hoàn lại.
Gavin phần lớn đã làm thay đổi tinh tế tầm nhìn của Ethereum: từ một nền tảng để xây dựng tiền tệ lập trình được — nền tảng có các hợp đồng dựa trên blockchain, có thể nắm giữ tài sản kỹ thuật số và chuyển theo các quy tắc được thiết lập sẵn — sang một nền tảng tính toán tổng quát. Sự thay đổi này bắt đầu từ những thay đổi tinh tế trong trọng tâm và thuật ngữ của Ethereum, và ảnh hưởng này ngày càng gia tăng khi chúng tôi ngày càng nhấn mạnh vào tích hợp Web3 (coi Ethereum là một phần của bộ công nghệ phi tập trung, hai phần còn lại là Whisper và Swarm, Hình 1).
Vào đầu năm 2014, chúng tôi cũng thực hiện một số sửa đổi theo đề xuất của người khác. Sau khi Andrew Miller và những người khác đề xuất quay lại kiến trúc dựa trên ngăn xếp, cuối cùng chúng tôi đã quay lại (Hình 2).
Charles Hoskinson đề nghị chúng tôi chuyển từ SHA256 của Bitcoin sang SHA3 mới hơn (hoặc chính xác hơn, keccak256). Dù từng gây tranh cãi trong một thời gian, nhưng qua thảo luận với Gavin, Andrew và những người khác, chúng tôi xác định kích thước giá trị trong ngăn xếp nên bị giới hạn ở 32 byte. Một phương án thay thế — số nguyên không giới hạn — vẫn được cân nhắc, vì nó gặp vấn đề khó tính toán chính xác cần bao nhiêu nhiên liệu để thực hiện các phép cộng, nhân và các thao tác khác.
Trở lại tháng 1 năm 2014, thuật toán khai thác ban đầu chúng tôi nghĩ đến là thứ gọi là Dagger:
https://github.com/ethereum/wiki/blob/master/Dagger.md
Dagger được đặt tên theo Đồ thị Acyclic Có hướng (Directed Acyclic Graph - DAG), một cấu trúc toán học dùng trong thuật toán. Ý tưởng là cứ sau N khối, một DAG mới sẽ được tạo ngẫu nhiên từ một hạt giống. Dưới cùng, DAG sẽ là một tập hợp các nút cần hàng tỷ byte để lưu trữ. Tuy nhiên, để tạo bất kỳ giá trị độc lập nào trong DAG, chỉ cần tính toán vài nghìn mục. Một phép tính Dagger bao gồm việc lấy một số lượng giá trị tại các vị trí tùy ý trong tập dữ liệu底层, rồi cùng nhau băm chúng. Điều này có nghĩa là có một cách nhanh để thực hiện phép tính Dagger — đã lưu dữ liệu trong bộ nhớ, và một cách chậm hơn nhưng không gây áp lực bộ nhớ — tái tạo từng giá trị bạn cần từ đầu trong DAG. Cách nhanh có thể chỉ mất vài micro giây, trong khi cách chậm và nhẹ bộ nhớ có thể mất vài mili giây, vì vậy vẫn khả thi với client nhẹ.
Mục đích của thuật toán này là có thuộc tính giới hạn bộ nhớ giống như thuật toán Scrypt phổ biến lúc đó, nhưng vẫn thân thiện với client nhẹ. Thợ đào sẽ dùng cách nhanh, do đó việc khai thác của họ bị giới hạn bởi băng thông bộ nhớ (về lý thuyết, bộ nhớ cấp người tiêu dùng đã được tối ưu hóa đủ cao, nên rất khó để ASIC tối ưu thêm), nhưng client nhẹ có thể xác minh bằng cách chậm và ít tốn bộ nhớ. Phương pháp nhanh có thể chỉ mất vài micro giây, trong khi phương pháp chậm và ít tốn bộ nhớ có thể mất vài mili giây, vì vậy vẫn khả thi với client nhẹ.
Từ đây, thuật toán này đã trải qua vài lần thay đổi cùng với sự phát triển của Ethereum. Ý tưởng tiếp theo là Proof of Work thích ứng. Trong phương án này, PoW sẽ liên quan đến việc thực thi các hợp đồng Ethereum được chọn ngẫu nhiên, và có một cách khéo léo để chống ASIC: nếu ASIC được phát triển, các thợ đào cạnh tranh sẽ có động lực tạo và công bố các hợp đồng mà ASIC đó thực thi kém. Không có ASIC nào có thể xử lý tính toán tổng quát, vì bản thân nó chỉ là một CPU. Vì vậy, chúng ta có thể tận dụng cơ chế đối kháng này để thực hiện về bản chất là PoW tính toán tổng quát.
Ý tưởng này sau đó tan vỡ vì một lý do đơn giản: tấn công chuỗi dài. Kẻ tấn công có thể bắt đầu xây dựng chuỗi từ khối 1 và chỉ điền vào đó bằng các hợp đồng đơn giản. Cần lưu ý rằng kẻ tấn công có thể thiết kế phần cứng chuyên dụng cho các hợp đồng đơn giản này, giúp chuỗi tấn công nhanh chóng vượt qua chuỗi chính. Vậy là... quay lại vạch xuất phát.
Thuật toán tiếp theo được gọi là "mạch ngẫu nhiên", mô tả chi tiết có thể xem trong tài liệu Google của nó. Ý tưởng này do tôi và Vlad Zamfir đưa ra, và được Matthew Wampler-Doty cùng những người khác phân tích. Tư tưởng của thuật toán này là mô phỏng tính toán tổng quát trong thuật toán khai thác bằng cách thực thi mạch được tạo ngẫu nhiên. Lần này, không có bằng chứng chắc chắn nào cho thấy thứ dựa trên những nguyên tắc này là vô hiệu. Nhưng các chuyên gia phần cứng máy tính mà chúng tôi tiếp xúc vào năm 2014 đều tỏ ra rất bi quan. Matthew Wampler-Doty đề xuất một PoW dựa trên giải pháp SAT, nhưng cuối cùng cũng bị từ chối.
Cuối cùng, sau nhiều vòng quanh co, chúng tôi đưa ra thuật toán Dagger Hashimoto, đôi khi gọi tắt là Dashimoto. Thuật toán này mượn nhiều ý tưởng từ Hashimoto. Hashimoto là cơ chế PoW do Thaddeus Dryja đề xuất, người khởi xướng khái niệm "PoW ràng buộc I/O". Trong cơ chế này, yếu tố giới hạn tốc độ khai thác chủ yếu không phải là tốc độ băm mỗi giây, mà là số megabyte RAM có thể truy cập mỗi giây. Tuy nhiên, Dagger Hashimoto kết hợp cơ chế PoW này với tập dữ liệu được tạo bởi DAG trong thuật toán Dagger, vốn thân thiện với client nhẹ. Sau nhiều lần điều chỉnh của tôi, Matthew, Tim và những người khác, những ý tưởng này cuối cùng được tích hợp vào thuật toán mà ngày nay chúng ta gọi là "Ethash".
Đến mùa hè năm 2014, ngoài PoW dự kiến sẽ đạt đến Ethash vào đầu năm 2015, giao thức đã khá ổn định, và đặc tả bán chính thức của nó đã xuất hiện dưới dạng Sách vàng của Gavin.
Tháng 8 năm 2014, tôi phát triển và giới thiệu cơ chế khối chú (uncle block). Cơ chế này cho phép blockchain Ethereum có thời gian khối ngắn hơn và khả năng xử lý cao hơn, đồng thời giảm rủi ro tập trung. Giới thiệu về cơ chế khối chú có thể xem trong PoC6.
Sau khi thảo luận với nhóm BitShares, chúng tôi cân nhắc sử dụng heap làm cấu trúc dữ liệu hạng nhất — mặc dù cuối cùng không làm được do thiếu thời gian, và sau này các cuộc kiểm tra an toàn và tấn công DoS khiến chúng tôi nhận ra: triển khai an toàn chức năng này vào lúc đó khó hơn nhiều so với tưởng tượng.
Tháng 9, tôi và Gavin lên kế hoạch thực hiện hai thay đổi lớn đối với thiết kế giao thức. Thứ nhất, ngoài cây trạng thái và cây giao dịch, mỗi khối sẽ còn chứa thêm một cây biên lai. Cây biên lai sẽ chứa băm của nhật ký do mỗi giao dịch tạo ra và gốc trạng thái trung gian. Nhật ký sẽ cho phép giao dịch tạo ra đầu ra được lưu trên blockchain và có thể truy cập bởi client nhẹ. Tuy nhiên, các tính toán trạng thái trong tương lai không thể truy cập những nhật ký này. Phương pháp này cho phép các ứng dụng phi tập trung dễ dàng truy vấn các sự kiện như chuyển token, mua hàng, đơn đặt lệnh sàn giao dịch đang được tạo và khớp, cũng như các cuộc đấu giá đang diễn ra.
Chúng tôi cũng cân nhắc các ý tưởng khác, như trích xuất cây Merkle từ toàn bộ lộ trình thực thi giao dịch để cho phép chứng minh nội dung tùy ý. Sau khi cân nhắc giữa tính đơn giản và toàn diện, chúng tôi chọn sử dụng nhật ký.
Thứ hai là ý tưởng về các hợp đồng tiền biên dịch (precompiles). Tiền biên dịch giải quyết vấn đề cho phép các phép tính mật mã phức tạp có sẵn trong EVM mà không phải chịu chi phí hoạt động của EVM. Chúng tôi cũng từng đưa ra nhiều ý tưởng tham vọng về các hợp đồng nội địa. Trong những ý tưởng đó, nếu thợ đào có phương pháp thực hiện tốt hơn cho một số hợp đồng nhất định, họ sẽ bỏ phiếu giảm giá nhiên liệu cho các hợp đồng đó. Như vậy, các hợp đồng mà đa số thợ đào có thể thực thi nhanh sẽ tự nhiên có giá nhiên liệu thấp hơn. Tuy nhiên, tất cả các ý tưởng này đều bị từ chối, vì chúng tôi không thể đề xuất cách thực hiện nào đủ an toàn về mặt kinh tế mật mã. Kẻ tấn công luôn có thể tạo các hợp đồng thực hiện các thao tác mật mã có cửa hậu, sau đó phân phát cửa hậu cho bản thân và bạn bè, để có thể thực thi hợp đồng nhanh hơn. Sau đó, kẻ tấn công bỏ phiếu giảm giá nhiên liệu và lợi dụng điều này để tấn công DoS mạng. Thay vào đó, chúng tôi chọn một phương pháp ít tham vọng hơn: đơn giản là chỉ định một số lượng nhỏ tiền biên dịch trong giao thức cho các thao tác thường dùng như băm và các lược đồ chữ ký.
Gavin cũng là nhân vật then chốt ban đầu ủng hộ ý tưởng phát triển sự trừu tượng hóa giao thức. Trừu tượng hóa giao thức nghĩa là chuyển nhiều phần của giao thức, như số dư ether, thuật toán ký giao dịch, nonce,... thành các hợp đồng bên trong chính giao thức. Mục tiêu lý thuyết cuối cùng là toàn bộ giao thức Ethereum có thể được mô tả như việc thêm các lời gọi hàm vào một máy ảo với trạng thái khởi tạo cụ thể. Chúng tôi không có đủ thời gian để đưa tất cả những ý tưởng này vào phiên bản Frontier ban đầu, nhưng dự kiến các nguyên tắc này sẽ dần được tích hợp thông qua một số thay đổi ở "Constantinople", hợp đồng Casper và đặc tả phân mảnh.
Tất cả những nội dung này đều được triển khai trong PoC7. Sau PoC7, giao thức không thực sự thay đổi nhiều, ngoại trừ một vài điều chỉnh nhỏ nhưng trong một số trường hợp rất quan trọng. Những chi tiết này sẽ được công bố sau kiểm tra an toàn.
Đầu năm 2015, Jutta Steiner và những người khác tổ chức kiểm toán an toàn trước khi phát hành, bao gồm kiểm toán mã phần mềm và kiểm toán học thuật. Kiểm toán phần mềm chủ yếu được thực hiện trên các triển khai C++ và Go do Gavin và Jeffry dẫn đầu. Mặc dù triển khai Pyethereum của tôi cũng trải qua một cuộc kiểm toán đơn giản. Trong hai cuộc kiểm toán học thuật, một cuộc do Ittay Eyal (nổi tiếng với "khai thác ích kỷ") đảm nhiệm, cuộc còn lại do Andrew Miller và các thành viên khác của Least Authority thực hiện. Kiểm toán của Eyal dẫn đến một thay đổi nhỏ trong giao thức: tổng độ khó của chuỗi sẽ không bao gồm các khối chú. Kiểm toán của Least Authority tập trung hơn vào hợp đồng thông minh, kinh tế nhiên liệu và cây Patricia. Cuộc kiểm toán này cũng dẫn đến vài thay đổi giao thức. Một trong những thay đổi nhỏ là sử dụng sha3(addr) và sha3(key) làm khóa cho cây, thay vì dùng trực tiếp địa chỉ và khóa. Điều này khiến việc tấn công xấu nhất vào cây của kẻ tấn công trở nên khó khăn hơn.
Một vấn đề quan trọng khác mà chúng tôi thảo luận là cơ chế bỏ phiếu giới hạn nhiên liệu. Lúc đó, chúng tôi đã lo ngại về sự bế tắc trong tranh luận về kích thước khối Bitcoin, và hy vọng Ethereum có thiết kế linh hoạt: có thể điều chỉnh theo thời gian khi cần. Nhưng thách thức đặt ra là: giới hạn tốt nhất là gì? Ý tưởng ban đầu của tôi là thiết lập một giới hạn động, bằng 1,5 lần trung bình di động mũ dài hạn của mức sử dụng nhiên liệu thực tế. Do đó, về lâu dài, trung bình mỗi khối sẽ chiếm 2/3 dung lượng. Tuy nhiên, Andrew chứng minh giới hạn này có thể bị lợi dụng ở một số khía cạnh — cụ thể, các thợ đào muốn tăng giới hạn chỉ cần đưa vào khối của họ các giao dịch tiêu tốn nhiều nhiên liệu nhưng tốn rất ít thời gian xử lý, từ đó tạo ra khối đầy mà không bị lỗ. Vì vậy, ít nhất xét về kết quả cuối cùng, mô hình bảo mật của cơ chế này tương đương với việc để thợ đào bỏ phiếu trực tiếp về giới hạn nhiên liệu.
Chúng tôi không thể đề xuất chiến lược giới hạn nhiên liệu tốt hơn, và Andrew đề xuất để thợ đào bỏ phiếu rõ ràng về giới hạn nhiên liệu, với chiến lược mặc định là 1,5 lần EMA. Lý do là chúng tôi chưa nghĩ ra phương pháp đúng để thiết lập giới hạn nhiên liệu tối đa, và rủi ro thất bại của bất kỳ phương pháp cụ thể nào dường như cao hơn hẳn rủi ro thợ đào lạm dụng quyền bỏ phiếu. Vì vậy, thà cứ đơn giản để thợ đào bỏ phiếu về giới hạn nhiên liệu, chấp nhận rủi ro giới hạn quá cao hoặc quá thấp, để đổi lấy tính linh hoạt và lợi ích là các thợ đào có thể nhanh chóng điều chỉnh giới hạn theo nhu cầu.
Sau một mini hackathon giữa tôi, Gavin và Jeff, PoC9 cuối cùng được ra mắt vào tháng 3. Nó nhằm trở thành phiên bản cuối cùng của bản mẫu khái niệm. Chúng tôi chạy một mạng thử nghiệm tên là "Olympic" trong 4 tháng, sử dụng giao thức sẽ dùng trên mạng chính. Đồng thời, chúng tôi cũng xây dựng kế hoạch dài hạn cho Ethereum. Vinay Gupta đã viết một bài — "Quy trình phát hành Ethereum", mô tả 4 giai đoạn phát triển mạng chính Ethereum, và đặt ra các tên quen thuộc ngày nay: "Frontier", "Homestead", "Metropolis" và "Serenity".
Mạng thử nghiệm "Olympic" chạy trong 4 tháng. Hai tháng đầu, chúng tôi phát hiện rất nhiều lỗi trong các phiên bản triển khai khác nhau, cũng như các vấn đề khác như thất bại đồng thuận. Tuy nhiên, khoảng tháng 6, mạng đã ổn định đáng kể. Đến tháng 7, chúng tôi quyết định đóng băng mã nguồn; ngày 30 tháng 7, mạng chính Ethereum chính thức ra mắt.
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
@VitalikButerin
