Câu chuyện trước khi Ethereum ra mắt

• tác giả: Vitalik Buterin *

• tiêu đề gốc: 《A Prehistory of the Ethereum Protocol》 *

• thời gian xuất bản: Ngày 14 tháng 9 năm 2017 *

Mặc dù ý tưởng đứng sau giao thức Ethereum hiện tại đã cơ bản ổn định trong hai năm, nhưng Ethereum không xuất hiện ngay lập tức và chưa hoàn toàn hình thành trong khái niệm hiện tại. Trước khi blockchain được khởi động, giao thức đã trải qua nhiều phát triển và quyết định thiết kế quan trọng. Mục đích của bài viết này là xem xét các biến thể khác nhau của giao thức từ khi khởi động; công việc vô số đã được thực hiện trong các triển khai giao thức như Geth, Cppethereum, Pyethereum và Ethereumj, cũng như lịch sử ứng dụng và doanh nghiệp trong hệ sinh thái Ethereum, là cố ý nằm ngoài phạm vi.

Lịch sử của nghiên cứu Casper và Sharding cũng xuất hiện. Mặc dù chúng tôi chắc chắn có thể xuất bản nhiều bài viết blog hơn, thảo luận về tất cả những ý tưởng của Vlad, Gavin, bản thân tôi và những người khác, bao gồm "bằng chứng công việc", "chuỗi nan hoa", "siêu lập pháp", chuỗi bóng (có thể nói là tiền thân của Plasma), sợi chuỗi và các biến thể khác nhau của Casper, cũng như Vlad (Vlad trong một bài viết, chúng tôi sẽ bỏ qua bây giờ.

Hãy bắt đầu từ phiên bản đầu tiên cuối cùng trở thành Ethereum, khi nó thậm chí còn chưa được gọi là Ethereum. Khi tôi đến thăm Israel vào tháng 10 năm 2013, tôi đã dành nhiều thời gian với nhóm Mastercoin và thậm chí đã cung cấp cho họ một số tính năng. Sau vài lần suy nghĩ về những gì họ đang làm, tôi đã gửi cho nhóm một đề xuất để làm cho giao thức trở nên phổ quát hơn và hỗ trợ nhiều loại hợp đồng hơn mà không cần thêm các tính năng lớn và phức tạp như nhau:

https://web.archive.org/web/20150627031414/http://vbuterin.com/ultimatescripting.html

Xin lưu ý rằng điều này rất khác với tầm nhìn rộng lớn hơn sau này của Ethereum: nó hoàn toàn là những gì Mastercoin cố gắng nghiên cứu chuyên sâu, tức là hợp đồng hai bên, nơi bên A và bên B đều đầu tư tiền, và sau đó họ sẽ nhận được tiền theo một số công thức nhất định được chỉ định trong hợp đồng (ví dụ, một cược sẽ nói: "Nếu X xảy ra, thì tất cả tiền sẽ được giao cho A, nếu không thì sẽ giao cho B"). Ngôn ngữ kịch bản không hoàn chỉnh.

Nhóm Mastercoin ấn tượng, nhưng họ không quan tâm đến việc từ bỏ mọi thứ họ đang làm để phát triển theo hướng này, và tôi ngày càng tin rằng đó là lựa chọn đúng đắn. Do đó, đây là phiên bản 2 vào ngày 2 tháng 12:

https://web.archive.org/web/20131219030753/http://vitalik.ca/ethereum.html

Tại đây, bạn có thể thấy kết quả của một nghiên cứu lại có ý nghĩa, chủ yếu là do tôi nhận ra rằng hợp đồng thông minh có khả năng tổng quát hoàn toàn là kết quả của một chuyến đi dài đến San Francisco. Thay vì chỉ đơn thuần là một ngôn ngữ kịch bản mô tả các điều khoản của mối quan hệ giữa hai bên, hợp đồng bản thân nó là một tài khoản hoàn chỉnh và có khả năng giữ, gửi và nhận tài sản, thậm chí giữ lưu trữ vĩnh viễn (vào thời điểm đó, lưu trữ vĩnh viễn đượ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 tính dựa trên ngăn xếp sang máy tính dựa trên thanh ghi của chính tôi; ngoài những trường hợp có vẻ phức tạp hơn, tôi gần như không có tranh luận về điều này.

Hơn nữa, xin lưu ý rằng bây giờ có một cơ chế phí tích hợp:

Tại thời điểm này, Ether thực sự là gas. Sau mỗi bước tính toán, số dư của hợp đồng mà sàn giao dịch yêu cầu sẽ giảm, và nếu hợp đồng hết tiền để thực hiện, nó sẽ dừng lại. Xin lưu ý rằng cơ chế "người nhận trả phí" này có nghĩa là hợp đồng bản thân phải yêu cầu người gửi trả phí cho hợp đồng, và ngay lập tức thoát ra nếu không có phí này; giao thức phân bổ 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í.

Đây là lúc giao thức Ethereum hoàn toàn là sáng tạo của riêng tôi. Tuy nhiên, từ đây, những người tham gia mới bắt đầu gia nhập vào cuộc chơi. Đến thời điểm này, người nổi bật nhất trong khía cạnh giao thức là Gavin Wood, người đã liên hệ với tôi vào tháng 12 năm 2013.

Trưởng nhóm phát triển khách hàng GO, Jeffrey Wilcke (lúc đó được gọi là "Ethereal") cũng đã liên hệ vào khoảng thời gian tương tự, mặc dù đóng góp của anh ấy chủ yếu trong phát triển khách hàng hơn là nghiên cứu giao thức.

"Chào, Jeffrey, thật vui khi thấy bạn quan tâm đến Ethereum…"

Đóng góp ban đầu của Gavin là hai lần. Đầu tiên, bạn có thể nhận thấy rằng 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 ra "giao dịch nội bộ" cho hợp đồng B ("giao dịch nội bộ" là thuật ngữ của Etherscan; ban đầu, chúng chỉ được gọi là "giao dịch" và sau đó, sau này là "gọi tin nhắn" hoặc "gọi"), cho đến khi việc thực hiện giao dịch đầu tiên hoàn tất, việc thực hiện giao dịch nội bộ mới bắt đầu. Điều này có nghĩa là giao dịch không thể sử dụng giao dịch nội bộ như một cách để lấy thông tin từ các hợp đồng khác; cách duy nhất là OpCode Extro (giống như bạn có thể sử dụng để đọc dữ liệu lưu trữ của hợp đồng khác là Sload), sau đó cũng đã bị loại bỏ với sự hỗ trợ của Gavin và những người khác.

Khi thực hiện thông số kỹ thuật ban đầu của tôi, Gavin một cách tự nhiên đã đồng bộ hóa việc thực hiện giao dịch nội bộ mà không nhận ra rằng ý định là khác nhau - tức là, trong việc thực hiện của Gavin, khi hợp đồng gọi một hợp đồng khác, giao dịch nội bộ sẽ được thực hiện ngay lập tức, và khi việc thực hiện hoàn tất, VM sẽ quay lại hợp đồng tạo ra giao dịch nội bộ và tiếp tục với OPCODE tiếp theo. Trong mắt cả hai chúng tôi, phương pháp này dường như là ưu việt, vì vậy chúng tôi quyết định đưa nó vào như một phần của thông số kỹ thuật.

Thứ hai, cuộc thảo luận giữa anh ấy và tôi (trong khi đi bộ ở San Francisco, chi tiết chính xác sẽ mãi mãi bị gió lịch sử thổi bay, có thể mất một hoặc hai bản sao trong hồ sơ sâu của NSA) đã chuyển mô hình phí giao dịch từ phương pháp "hợp đồng trả phí" sang phương pháp "người gửi trả phí", và cũng chuyển sang kiến trúc "gas". Người gửi giao dịch không lấy đi từng bước giao dịch riêng lẻ ngay lập tức, mà phân bổ một số "gas" (đại khái là phản hồi của các bước tính toán), và các bước tính toán sẽ lấy từ khoản trợ cấp gas này. Nếu một giao dịch hết gas, gas vẫn sẽ bị tịch thu, nhưng toàn bộ việc thực hiện sẽ được khôi phục; điều này dường như là điều an toàn nhất, vì nó xóa bỏ toàn bộ khóa học"

Gavin cũng có thể được ghi nhận phần lớn cho tầm nhìn về việc xem Ethereum như một nền tảng xây dựng tiền tệ lập trình được, với các hợp đồng dựa trên blockchain có thể giữ tài sản kỹ thuật số và chuyển chúng theo các quy tắc đã được thiết lập trước, cho đến nền tảng tính toán tổng quát. Điều này bắt đầu từ sự thay đổi tinh tế trong trọng tâm và thuật ngữ, sau đó với sự gia tăng tầm quan trọng của bản giao hưởng "Web 3", bản giao hưởng này xem Ethereum như một tập hợp các công nghệ phân tán, hai cái khác là Whisper và Swarm.

Những người khác cũng đã đề xuất thay đổi vào khoảng đầu năm 2014. Sau khi Andrew Miller và những người khác đưa ra ý tưởng này, chúng tôi cuối cùng đã quay trở lại kiến trúc dựa trên ngăn xếp.

Charles Hoskinson đã đề xuất chuyển từ SHA256 của Bitcoin sang SHA3 mới (hoặc chính xác hơn là Keccak256). Mặc dù có một thời gian tranh cãi, nhưng cuộc thảo luận với Gavin, Andrew và những người khác đã dẫn đến việc xác định kích thước giá trị trên ngăn xếp nên bị giới hạn ở 32 byte. Một lựa chọn thay thế khác được xem xét là số nguyên kích thước vô hạn, có một vấn đề là khó khăn trong việc xác định bao nhiêu gas, phép cộng, phép nhân và các phép toán khác.

Thuật toán khai thác ban đầu mà chúng tôi nghĩ ra vào tháng 1 năm 2014 là một thiết bị có tên là Dagger:

https://github.com/ethereum/wiki/blob/master/Dagger.md

Dagger được đặt tên theo "đồ thị không chu trình có hướng" (DAG) mà cấu trúc toán học được sử dụng trong thuật toán này. Ý tưởng là, mỗi n khối, một dag mới sẽ được tạo ra từ hạt giống một cách giả ngẫu nhiên, và đáy của dag sẽ là một tập hợp các nút cần hàng chục gigabyte để lưu trữ. Tuy nhiên, việc tạo ra bất kỳ giá trị cá nhân nào trong DAG cần tính toán hàng nghìn mục. "Tính toán Dagger" liên quan đến việc lấy một số giá trị ở các vị trí ngẫu nhiên trong tập dữ liệu đáy này, sau đó kết hợp chúng lại. Điều này có nghĩa là có một cách nhanh chóng để thực hiện tính toán Dagger - dữ liệu đã được lưu trữ trong bộ nhớ, thay vì phương pháp tốn bộ nhớ - từ mỗi giá trị mà bạn cần lấy từ đầu.

Mục tiêu của thuật toán là có thuộc tính "tính nhớ" giống như các thuật toán phổ biến vào thời điểm đó, chẳng hạn như Scrypt, nhưng vẫn thân thiện với khách hàng nhẹ. Các thợ mỏ sẽ sử dụng cách nhanh chóng, vì vậy việc khai thác của họ sẽ bị giới hạn bởi băng thông bộ nhớ (về lý thuyết, RAM tiêu dùng đã rất được coi trọng, vì vậy rất khó để tối ưu hóa nó hơn nữa bằng ASIC), nhưng khách hàng nhẹ có thể sử dụng phiên bản không có bộ nhớ nhưng chậm hơn để xác thực. Cách nhanh chóng có thể mất vài micro giây, và cách không có bộ nhớ chậm mà không cần mili giây, vì vậy đối với khách hàng nhẹ, nó vẫn rất khả thi.

Từ đây, trong quá trình phát triển Ethereum, thuật toán sẽ trải qua nhiều thay đổi. Ý tưởng tiếp theo mà chúng tôi trải qua là "bằng chứng công việc thích ứng". Tại đây, bằng chứng công việc sẽ liên quan đến việc thực hiện các hợp đồng Ethereum được chọn ngẫu nhiên, và có một lý do thông minh về cách mà điều này sẽ chống lại ASIC: nếu ASIC được phát triển, thì các thợ mỏ cạnh tranh sẽ có động lực để tạo ra và phát hành nhiều hợp đồng, mô tả rằng các hợp đồng này không giỏi trong việc thực hiện. Câu chuyện này không có gì cho những thứ như ASIC cho tính toán tổng quát, vì đó chỉ là CPU, vì vậy chúng tôi có thể sử dụng cơ chế khuyến khích chống lại này để thực hiện cơ bản là bằng chứng công việc cho tính toán tổng quát.

Lý do thất bại rất đơn giản: tấn công từ xa. Kẻ tấn công có thể bắt đầu một chuỗi từ khối 1, chỉ với các hợp đồng đơn giản mà họ có thể tạo ra phần cứng chuyên dụng cho, và nhanh chóng vượt qua chuỗi chính. Vì vậy… quay lại bảng vẽ.

Thuật toán tiếp theo được gọi là "mạch ngẫu nhiên", được mô tả trong tài liệu Google này, do tôi và Vlad Zamfir đề xuất, và được phân tích bởi Matthew Wampler-Doty và những người khác. Ý tưởng ở đây cũng là để mô phỏng tính toán tổng quát trong thuật toán khai thác, lần này là thông qua việc thực hiện các mạch được tạo ra ngẫu nhiên. Không có gì khó để chứng minh, dựa trên những nguyên tắc này là không khả thi, nhưng các chuyên gia phần cứng máy tính mà chúng tôi đã liên hệ vào năm 2014 thường rất bi quan về điều này. Matthew Wampler-Doty bản thân đã đề xuất bằng chứng công việc dựa trên SAT, nhưng cuối cùng cũng bị từ chối.

Cuối cùng, chúng tôi hoàn thiện mạch bằng một thuật toán được gọi là "Dagger Hashimoto". "dashimoto" đôi khi được gọi là "dashimoto", đã vay nhiều ý tưởng từ hashimoto, Hashimoto là thuật toán bằng chứng công việc của Thaddeus Dryja, đã tiên phong đưa ra khái niệm "bằng chứng công việc I/O", trong đó yếu tố giới hạn chính của tốc độ khai thác không phải là hash mỗi giây, mà là phạm vi lớn của truy cập RAM mỗi giây. Tuy nhiên, nó kết hợp điều này với tập dữ liệu DAG thân thiện với khách hàng nhẹ của Dagger. Sau khi tôi đã thực hiện nhiều điều chỉnh, Matthew, Tim và những người khác, những ý tưởng này cuối cùng đã hòa nhập vào thuật toán mà chúng tôi hiện gọi là ethash.

Đến mùa hè năm 2014, giao thức đã ổn định đáng kể, ngoài thuật toán bằng chứng công việc, giao thức đã không đạt đến giai đoạn Ethash cho đến đầu năm 2015, và tồn tại dưới dạng thông số kỹ thuật bán chính thức trong sách vàng của Gavin.

Vào tháng 8 năm 2014, tôi đã phát triển và giới thiệu cơ chế khối chú, cơ chế này giúp chuỗi khối Ethereum có thời gian khối ngắn hơn và dung lượng cao hơn, đồng thời giảm thiểu rủi ro tập trung hóa. Điều này được giới thiệu như một phần của POC6.

Cuộc thảo luận với nhóm Bitshares đã dẫn đến việc chúng tôi xem xét việc thêm ngăn xếp như một cấu trúc dữ liệu hàng đầu, mặc dù do thiếu thời gian, chúng tôi cuối cùng đã không làm như vậy, và các cuộc kiểm tra bảo mật và tấn công DOS sau này sẽ chỉ ra rằng thực tế nó khó hơn nhiều so với những gì chúng tôi đã nghĩ đến để thực hiện điều này một cách an toàn.

Vào tháng 9, tôi và Gavin đã lên kế hoạch cho hai thay đổi lớn tiếp theo trong thiết kế giao thức. Đầu tiên, bên cạnh cây trạng thái và cây giao dịch, mỗi khối cũng sẽ chứa một "cây biên nhận". Cây biên nhận sẽ bao gồm băm của nhật ký giao dịch được tạo ra và gốc trạng thái trung gian. Nhật ký sẽ cho phép các giao dịch tạo ra "đầu ra" được lưu trữ trong chuỗi khối, và có thể được truy cập bởi khách hàng nhẹ, nhưng tính toán trạng thái tương lai sẽ không thể truy cập. Điều này có thể được sử dụng để cho phép các ứng dụng phân tán dễ dàng truy vấn các sự kiện, chẳng hạn như chuyển token, mua, tạo và điền đơn đặt hàng trao đổi, bắt đầu đấu giá, v.v.

Còn nhiều ý tưởng khác được xem xét, chẳng hạn như tạo ra cây Merkle từ toàn bộ dấu vết thực thi của giao dịch để chứng minh bất kỳ điều gì. Việc chọn nhật ký là vì chúng là sự thỏa hiệp giữa sự đơn giản và tính toàn vẹn.

Thứ hai là ý tưởng "tiền biên dịch", giải quyết vấn đề cho phép các tính toán mật mã phức tạp có sẵn trong EVM mà không cần xử lý chi phí EVM. Chúng tôi cũng đã trải qua những ý tưởng tham vọng hơn về "hợp đồng địa phương" "nếu thợ mỏ có thể tối ưu hóa việc thực hiện một số hợp đồng, họ có thể "bỏ phiếu" cho phí đóng gói của những hợp đồng này, do đó các hợp đồng mà phần lớn thợ mỏ có thể thực hiện nhanh hơn sẽ tự nhiên giảm giá gas; tuy nhiên, tất cả những ý tưởng này đã bị từ chối vì chúng tôi không thể đưa ra một phương pháp an toàn về kinh tế để thực hiện những điều như vậy. Kẻ tấn công luôn có thể tạo ra một hợp đồng, hợp đồng này thực hiện một số thao tác mật mã có cạm bẫy, phân bổ cạm bẫy cho chính họ và bạn bè của họ để thực hiện hợp đồng này nhanh hơn, sau đó thực hiện hợp đồng này và bỏ phiếu cho gas và sử dụng nó cho mạng. Ngược lại, chúng tôi đã chọn phương pháp tham vọng hơn, đó là đơn giản chỉ định một số lượng nhỏ các tiền biên dịch trong giao thức cho các thao tác phổ biến như băm và các phương pháp ký.

Gavin cũng là tiếng nói ban đầu quan trọng trong việc phát triển khái niệm "trừu tượng giao thức" - di chuyển nhiều phần của giao thức, chẳng hạn như số dư Ether, thuật toán ký giao dịch, nonces, v.v. như chính hợp đồng, và có khả năng đạt được mục tiêu cuối cùng lý thuyết là có thể mô tả toàn bộ giao thức Ethereum như một trường hợp gọi hàm vào máy ảo với một số trạng thái nguyên thủy. Những ý tưởng này không có đủ thời gian để vào phiên bản đầu tiên, nhưng các nguyên tắc dự kiến sẽ bắt đầu được tích hợp chậm chạp thông qua một số thay đổi ở Constantinople, hợp đồng Casper và quy định phân đoạn.

Tất cả những điều này đã được thực hiện trong POC7; sau POC7, giao thức không có nhiều thay đổi lớn, ngoại trừ những thay đổi nhỏ, mặc dù trong một số trường hợp rất quan trọng, nhưng chi tiết sẽ được đưa ra thông qua các cuộc kiểm tra bảo mật…

Đầu năm 2015, Jutta Steiner và những người khác đã tổ chức một cuộc kiểm toán an ninh trước phát hành, bao gồm kiểm tra mã phần mềm và kiểm tra học thuật. Cuộc kiểm tra phần mềm chủ yếu được dẫn dắt bởi Gavin Wood và Jeffrey Wilcke cho các triển khai C++ và GO, mặc dù cũng có một cuộc kiểm tra nhỏ cho triển khai Pyethereum của tôi. Trong hai cuộc kiểm tra học thuật này, một cuộc được thực hiện bởi Ittay Eyal (nổi tiếng với "khai thác ích kỷ"), cuộc còn lại bởi Andrew Miller và những người có thẩm quyền tối thiểu khác. Cuộc kiểm tra EYAL dẫn đến những thay đổi nhỏ trong giao thức: tổng độ khó của chuỗi không bao gồm các khối chú. Cuộc kiểm tra có quyền tối thiểu tập trung vào hợp đồng thông minh và kinh tế gas cũng như cây Patricia. Cuộc kiểm tra này dẫn đến một số thay đổi trong giao thức. Một thay đổi nhỏ là sử dụng sha3 (addr) và sha3 (key) làm khóa trie thay vì sử dụng địa chỉ và khóa trực tiếp; điều này sẽ làm cho các cuộc tấn công tồi tệ nhất vào Trie trở nên khó khăn hơn.

Cảnh báo có thể hơi xa so với thời đại của nó…

Một điều quan trọng khác mà chúng tôi đã thảo luận là cơ chế bỏ phiếu giới hạn gas. Vào thời điểm đó, chúng tôi đã lo ngại về sự thiếu tiến triển trong cuộc tranh luận về kích thước Bitcoin và muốn có một thiết kế linh hoạt hơn trong Ethereum, có thể điều chỉnh theo nhu cầu theo thời gian. Nhưng thách thức là: giới hạn tối ưu là gì? Ý tưởng ban đầu của tôi là thiết lập một giới hạn động, dựa trên trung bình động hàm mũ dài hạn của việc sử dụng gas thực tế, vì vậy về lâu dài, khối trung bình sẽ đầy. Tuy nhiên, Andrew, điều này có thể bị lợi dụng theo một số cách - đặc biệt là, những thợ mỏ muốn tăng giới hạn chỉ bao gồm các giao dịch trong khối của họ, những giao dịch tiêu tốn nhiều gas nhưng mất rất ít thời gian để xử lý, do đó luôn tạo ra toàn bộ khối mà không tốn tiền. Vì vậy, ít nhất theo hướng tăng, mô hình an toàn tương đương với việc đơn giản để thợ mỏ bỏ phiếu cho giới hạn gas.

Chúng tôi đã không thể nghĩ ra một chiến lược giới hạn gas khó bị phá vỡ, vì vậy giải pháp được Andrew đề xuất là đơn giản để thợ mỏ bỏ phiếu cho giới hạn gas, và đặt chiến lược bỏ phiếu mặc định là quy tắc EMA. Lý do là chúng tôi còn một chặng đường dài để đến phương pháp đúng để thiết lập giới hạn gas 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ư lớn hơn rủi ro lạm dụng quyền bỏ phiếu của thợ mỏ. Vì vậy, chúng tôi không ngần ngại để thợ mỏ bỏ phiếu cho giới hạn gas và chấp nhận rủi ro giới hạn quá cao hoặc quá thấp để đổi lấy lợi ích của tính linh hoạt, cũng như khả năng của thợ mỏ làm việc cùng nhau để điều chỉnh rất nhanh chóng theo nhu cầu lên hoặc xuống giới hạn.

Sau một cuộc marathon nhỏ giữa Gavin, Jeff và tôi, POC9 đã được phát hành vào tháng 3 và dự định trở thành bằng chứng cuối cùng cho việc phát hành khái niệm. Sử dụng kế hoạch dự kiến sẽ được sử dụng trong Livenet, và thiết lập kế hoạch dài hạn cho Ethereum, đã chạy thử nghiệm trong bốn tháng. Vinay Gupta đã viết một bài blog "Quá trình khởi động Ethereum", mô tả bốn giai đoạn dự kiến của phát triển Livenet Ethereum và đặt tên cho chúng: Frontier, Homestead, Metropolis và Serenity.

Cuộc marathon hacker đã kéo dài bốn tháng. Trong hai tháng đầu tiên, nhiều lỗi đã được phát hiện trong các triển khai khác nhau, đã xảy ra thất bại đồng thuận, bên cạnh nhiều vấn đề khác, nhưng vào khoảng tháng 6, mạng đã ổn định rõ rệt. Vào tháng 7, quyết định thực hiện đóng băng mã và sau đó phát hành, và đã phát hành vào ngày 30 tháng 7.