Khám phá JavaScript và Hợp đồng thông minh với Giám đốc điều hành Agoric Dean Tribble

Trong AMA này, chúng tôi rất vui được phỏng vấn Dean Tribble. Dean là Giám đốc điều hành của Agoric, và đã có một hành trình rộng lớn trong lĩnh vực công nghệ khi tham gia vào các dự án phần mềm và công ty khởi nghiệp khác nhau từ những năm 80. Anh ấy đã và đang theo đuổi tầm nhìn về các hệ thống máy tính nối mạng quy mô lớn và điều đó đã đưa anh ấy đến với các hợp đồng thông minh.

Chủ đề lười biếng này của Sara Pinto, Dean Tribble, Dimitar Bochvarovski, Pawan Sharma, Mónica Freitas và Limarc Ambalina xảy ra trên kênh #amas chính thức của slogging và đã được chỉnh sửa để dễ đọc.

Xin chào @channel, hãy cùng tôi chào đón vị khách AMA tiếp theo của chúng ta, Dean Tribble, Giám đốc điều hành của http://agoric.com . Agoric là một công ty phát triển mã nguồn mở khởi chạy một nền kinh tế và chuỗi Proof-of-Stake có thể tương tác.

Vui lòng hỏi Dean bất cứ điều gì về:

Xin chào! Cảm ơn bạn đã mời tôi!

Này Dean Tribble, thật tuyệt khi có bạn ở đây với chúng tôi. Chúng tôi có thể bắt đầu với việc bạn cho chúng tôi biết một chút về lý lịch của bạn được không?

Tôi có công việc máy tính đầu tiên khi tôi 15 tuổi, công ty khởi nghiệp đầu tiên của tôi (được tài trợ bởi người sáng lập Atari, Nolan Bushnell) khi tôi 17 tuổi. Vì vậy, tôi đã làm phần mềm và các công ty khởi nghiệp từ những năm 80. Phần lớn nó nằm trong việc xây dựng các hệ thống phân tán quy mô lớn.

Tôi đã theo đuổi tầm nhìn về các hệ thống máy tính nối mạng quy mô lớn trong nhiều thập kỷ. Tôi đã làm việc tại Xerox PARC (cùng với một số đồng nghiệp của tôi tại Agoric) về các hệ điều hành và ngôn ngữ lập trình phân tán an toàn ban đầu. Những hứa hẹn thời hiện đại trong JavaScript và RUST xuất phát từ công việc đó. Sau đó tôi đã làm việc trên siêu văn bản (trước khi có web) tại Xanadu. Ở đâu đó vào năm 1989, tôi đã làm việc với hợp đồng thông minh sản xuất đầu tiên (vâng, 5 năm trước khi Vitalik ra đời 🙂.

Kể từ đó, tôi đã làm việc trên rất nhiều hệ thống quy mô lớn từ hệ thống thông tin môi giới ban đầu bằng Java cho đến hợp đồng biểu diễn công cụ thanh toán trị giá hàng tỷ đô la trước đây của tôi. Thông thường, đó là việc đưa công nghệ mới ra thị trường để cho phép người lạ hợp tác thành công hơn!

Đó là những gì đã đưa tôi vào các hợp đồng thông minh ngay từ đầu: "phần mềm thực thi các điều khoản của một thỏa thuận giống như hợp đồng giữa nhiều bên" chỉ cho phép hợp tác nhiều hơn trên thế giới. Tất cả các doanh nghiệp từ eBay và PayPal đến AirBNB và Lyft đều là loại hình kinh doanh đó.

Tất cả những thứ đó đều yêu cầu một người trung gian đáng tin cậy và như chúng tôi biết không phải lúc nào họ cũng đáng tin cậy 🙂. Nhưng sau đó, blockchain ra đời cho phép các máy tính độc lập ở các khu vực pháp lý khác nhau chạy cùng một phần mềm và xác minh hoạt động của nhau và đột nhiên bạn có thể điều hành các doanh nghiệp hợp đồng thông minh mà không cần người trung gian đáng tin cậy. Đó là lý do khiến tôi bắt tay vào việc xây dựng cơ sở hạ tầng hợp đồng thông minh cho thế hệ blockchain tiếp theo. Và chúng tôi đây 🙂

Điều đó khiến tôi nhận ra rằng mình đã bỏ qua Sun và Microsoft trong đó.

Tại Sun Labs vào những năm 90, chúng tôi đã có một dự án xây dựng một nền tảng hợp đồng thông minh. Đó là một phần quan trọng của công việc thiết kế ban đầu dẫn đến các yếu tố của nền tảng hợp đồng thông minh JavaScript của Agoric.

Tại Microsoft, tôi là kiến trúc sư của hệ điều hành Midori (nghiên cứu), một hệ điều hành nghiên cứu sử dụng cùng phương pháp tiếp cận kiến trúc dựa trên thông điệp aysnc / ocap / promise mà chúng tôi hiện đang sử dụng trong Agoric vm / kernel.

Đúng là một nghề nghiệp 🙂

Tại sao lại sử dụng JavaScript? Ý tôi là, cá nhân tôi là một Nhà phát triển web và sử dụng JS trong cuộc sống hàng ngày và là ngôn ngữ mà tôi sẽ không thay đổi cho bất kỳ thứ gì khác, nhưng có rất nhiều cuộc thảo luận về các vấn đề đi kèm với JS, chẳng hạn như kiểu động và khả năng dễ mắc lỗi với quản lý bộ nhớ ...

Và tôi là một fan hâm mộ lớn của Kyle Simpson, phải kể đến. Anh ấy có các khóa học thú vị về khả năng đối tượng trong js

Tôi thích câu hỏi đó vì nó có cả câu trả lời không ngạc nhiên và đáng ngạc nhiên.

Câu trả lời không có gì đáng ngạc nhiên là “… là ngôn ngữ mà tôi sẽ không thay đổi vì bất cứ điều gì khác…”. 13,9 triệu nhà phát triển! Tôi muốn thấy nhiều sự hợp tác hơn trên thế giới và hợp đồng thông minh là một công cụ vô cùng mạnh mẽ để giúp điều đó xảy ra. Tuy nhiên, đối với điều đó, nó phải có sẵn cho hầu hết các lập trình viên trên thế giới. Sẽ không hữu ích nhiều nếu, để xây dựng một hợp đồng thông minh, bạn phải cầu nguyện với chức tư tế của các nhà phát triển Solidity đắt giá 10k. Thật dễ dàng hơn để tìm một luật sư giỏi và làm theo cách cổ điển! Vì vậy, chúng tôi bắt đầu gặp gỡ các nhà phát triển ở nơi họ đang ở và trao quyền cho họ để xây dựng các hợp đồng thông minh.

Câu trả lời đáng ngạc nhiên là JavaScript có tính bảo mật cao hơn hầu hết các ngôn ngữ lập trình khác, phần lớn là do sự đóng góp của Nhà khoa học trưởng Mark Miller của chúng tôi. Anh ấy đã hướng các yếu tố cần thiết vào JavaScript từ công việc ngôn ngữ an toàn trước đó của chúng tôi kể từ khi bắt đầu. Bài báo năm 2015 của ông về mật mã tài chính về “Các công cụ tài chính dựa trên năng lực” đã đưa ra các ví dụ bằng ngôn ngữ lập trình E mà giờ đây bạn có thể viết bằng JavaScript trên Agoric.

Lý do JS được bảo mật hơn một phần cũng là do lịch sử: ngôn ngữ JS được chuẩn hóa trong ECMA, trong khi môi trường máy chủ của trình duyệt cho nó được chuẩn hóa trong W3C. Điều đó tương ứng với sự phân tách chế độ người dùng / chế độ hệ thống được yêu cầu cho các hệ điều hành an toàn. Bạn chưa bao giờ thấy ranh giới thiết kế cũng như được bảo vệ như các ủy ban bảo vệ sân cỏ của họ 😄. Vì vậy, cách duy nhất mà một chương trình / mô-đun / bất cứ thứ gì JS có quyền đối với bất kỳ thứ gì trong hệ thống là nếu nó được đưa vào đối tượng toàn cục được sử dụng để đánh giá. Trong trình duyệt, toàn cầu đó bao gồm

 document

như vậy, trong khi trong nút, toàn cầu bao gồm

 fs

và

 process

và những thứ tương tự. Mark và những người khác đã giữ JS theo dõi đó. Và với một vài tính năng bổ sung (ví dụ:

 freeze

) chúng tôi có thể đánh giá mã JS (ví dụ: trên blockchain hoặc trong các máy chủ) trong đó quyền hạn duy nhất mà nó có được là đối với các dịch vụ cụ thể mà chúng tôi cung cấp. Nó không thể có được tại hệ thống tệp, mạng, v.v.

đó là "JavaScript cứng". Nó là mã nguồn mở, có sẵn cho web2 và web3 tại https://github.com/endojs/endo và chạy trong bất kỳ môi trường JS tiêu chuẩn nào. Nó là xương sống của ví thế hệ tiếp theo của MetaMask, được sử dụng trong AppExchange của Salesforce và tất nhiên được sử dụng cho nền tảng hợp đồng thông minh của chúng tôi.

Dean Tribble, thật không thể tin được! Bạn đã có một cuộc hành trình. Tôi phải hỏi, nhân danh những người không am hiểu về công nghệ, bạn có thể giải thích chi tiết về các hợp đồng thông minh trên blockchain không? Và bạn có nghĩa là gì về khả năng kết hợp?

Đối với hợp đồng thông minh là gì: "phần mềm thực thi các điều khoản của một thỏa thuận giống như hợp đồng giữa nhiều bên". Đó là nó! Do đó, eBay và PayPal và Lyft và StubHub phần lớn đều là hoạt động kinh doanh hợp đồng thông minh được triển khai bởi một “trung gian đáng tin cậy”. Vì vậy, các hợp đồng thông minh là $ 1T + vốn hóa thị trường * trước * blockchain. Chúng tôi dựa vào các trung gian để thực thi phần mềm của họ một cách trung thực và hầu hết các giao dịch được thực hiện mà không có bất kỳ sự tham gia nào của con người bởi công ty lưu trữ.

Các doanh nghiệp như vậy phát triển nhanh hơn nhiều khi có các thư viện và nền tảng tốt để nhanh chóng soạn các doanh nghiệp mới mà không cần mã hóa mọi thứ từ đầu (ví dụ: shopify, sọc, v.v. tất cả đều cung cấp các thành phần mà nhà phát triển có thể sử dụng lại).

Tại sao rất khó để đưa ra một "mã có thể được thực thi trên blockchain", đó là những gì hợp đồng thông minh nói chung (hãy sửa cho tôi nếu tôi sai) và chúng tôi cần đợi Ethereum ra mắt điều này dung dịch?

Nhưng ví dụ mô hình thành phần yêu thích của tôi là trong không gian giao diện người dùng (tôi đã làm việc trên giao diện người dùng với tư cách là thực tập sinh trong nhóm Smalltalk tại PARC). Trước React / vue / etc., Các chuyên gia có thể xây dựng một số thứ khá thú vị trong JavaScript. NHƯNG thật là một cơn ác mộng khi gỡ lỗi các ứng dụng ưa thích được viết bằng HTML / JS thô (Tôi vẫn nhớ lại lần cuối cùng tôi cố gắng gỡ lỗi tại sao thuế suất của một số trang mua hàng không thay đổi khi người dùng thay đổi mã zip của họ). React cung cấp khung thành phần cho các thành phần giao diện người dùng, giải quyết triệt để nhiều vấn đề khó khăn trong việc xây dựng giao diện người dùng ưa thích và hơn thế nữa, cho phép các thành phần do nhiều bên xây dựng có thể hoạt động cùng nhau cực kỳ hiệu quả.

Kết quả là ngay sau khi React ra mắt, các nhà phát triển mới có thể xây dựng các ứng dụng đẹp hơn, an toàn hơn, phản hồi nhanh hơn, hữu ích hơn các chuyên gia có thể làm vào năm trước React. Đó là những gì một khung thành phần giúp bạn.

Mục tiêu của chúng tôi là một khuôn khổ cung cấp cùng một loại hỗ trợ, nhưng dành cho các hợp đồng thông minh xử lý tài sản kỹ thuật số, định giá, v.v. (thay vì sử dụng nhấp chuột và hiển thị). Trong các nền tảng như Ethereum, có những mối nguy hiểm bảo mật có nguy cơ quá cao đối với các nhà khai thác tiền điện tử, chưa nói đến các nhà lập trình ứng dụng chỉ đang cố gắng giải quyết vấn đề kinh doanh của họ. Khung của chúng tôi được thiết kế để bảo vệ các nhà phát triển khỏi những mối nguy hiểm đó.

Vì vậy, một hợp đồng thông minh không phải là “mã có thể được thực thi trên một chuỗi khối”, vì đã có hơn 1 nghìn đô la giá trị trong các hợp đồng thông minh trước blockchain!

Bitcoin tự nó là một hợp đồng thông minh; đó là phần mềm thực thi các quy tắc chuyển BTC. Đây là hợp đồng thông minh đầu tiên không cần một bên trung gian đáng tin cậy.

Eth đã hỗ trợ cho việc chạy phần mềm của người khác. Có một số yêu cầu cho điều đó. Tiêu chuẩn vàng của blockchain là

nhiều máy tính ở các khu vực pháp lý khác nhau và các lĩnh vực quản trị khác nhau đều đạt được sự đồng thuận về dữ liệu, lựa chọn và tính toán.

Tôi sẽ giải nén nó, và sau đó nói về lý do tại sao nó quan trọng 🙂.

Hey Dean Tribble Bạn có thể vui lòng giải thích một chút về cung cấp an toàn trong Agoric và nó có hoàn lại tài sản ban đầu cộng với phí giao dịch hay chỉ tài sản ban đầu?

nhiều máy tính ở các khu vực pháp lý khác nhau và các miền quản trị khác nhau đều đạt được sự đồng thuận

Có nghĩa là không con người, tổ chức hoặc chính phủ nào có thể đơn phương thay đổi hành vi của hệ thống. Họ sẽ phải thỏa hiệp đồng thời với đa số máy móc (được kiểm soát bởi các bên khác) để thỏa hiệp tính toàn vẹn của tính toán.

về dữ liệu, lựa chọn và tính toán.

Dữ liệu: "Dean có 100 đô la trong tài khoản của anh ấy"
Lựa chọn: “Dean đã cố gắng rút lại lời đề nghị của mình trước khi cuộc đấu giá đóng cửa. Anh ta đã thắng cuộc đấu giá và tiêu tiền của mình hay anh ta lấy lại tiền của mình? ”
Tính toán: "cuộc đấu giá đã diễn ra và xác định rằng Dean sẽ là người chiến thắng"

Phần kỹ thuật khó mới là “tất cả đều đi đến sự đồng thuận”. Nếu bạn biết tất cả các máy tính (bạn không biết) và bạn có thể dựa vào tất cả chúng để không gian lận (bạn không thể), thì chúng tôi biết cách đếm phiếu bầu và đảm bảo đó là đa số. Lĩnh vực của Byzantine Fault Tolerance bao gồm việc xử lý “điều gì sẽ xảy ra nếu họ gian lận”. Cái nhìn sâu sắc nhất về BitCoin là cách giải quyết sự đồng thuận khi bạn không biết tất cả các máy tính tham gia.

Cuối cùng, để tất cả các máy tính đó kiểm tra xem chúng có đồng ý hay không, chúng phải thực sự đồng ý! Vì vậy, cùng một chương trình chạy với các đối số giống nhau nhiều lần ở nhiều nơi phải tạo ra các câu trả lời giống nhau (điều này được gọi là “xác định”). Điều đó hóa ra khó! Nếu họ có thể nhìn thấy đồng hồ, họ có thể cư xử khác. Nếu chúng có thể thấy bất kỳ địa chỉ bộ nhớ nào, chúng có thể hoạt động khác. Nếu họ có thể biết khi nào việc thu gom rác diễn ra,… bạn sẽ có ý tưởng.

Vì vậy, Solidity có rất nhiều vấn đề, và ở mức rất thấp, nhưng nó thực hiện một cách xác định. JavaScript cứng của chúng tôi cho phép bạn chạy JavaScript một cách xác định! Điều đó sẽ làm cho tất cả những điều này có thể tiếp cận được với nhiều nhà phát triển hơn

Pawan Sharma hỏi về "cung cấp sự an toàn" trong Agoric. Đó là một trong những thuộc tính quan trọng của khung hợp đồng thông minh. Các thuộc tính an toàn quen thuộc là những thứ như an toàn bộ nhớ và an toàn kiểu, nơi chúng chỉ loại bỏ hoàn toàn một số loại lỗi lớn. Họ không giải quyết được tất cả mọi thứ nhưng họ có thể loại bỏ 80% lỗi khỏi bàn.

Cung cấp an toàn là một tài sản an toàn ở cấp độ kinh tế.

Đầu tiên là cài đặt: Trong các hệ thống hợp đồng thông minh blockchain hiện tại, bạn thực hiện các giao dịch bằng cách gửi tiền đến một “số ngẫu nhiên” (địa chỉ tài khoản) và hy vọng điều gì đó tốt đẹp sẽ xảy ra. Mọi người đã gửi (và bị mất) tài sản đến các "địa chỉ" không phải là tài khoản thực, đó là tài khoản sai, đến các hợp đồng sau đó bị lỗi, v.v. Mô hình này vừa dễ xảy ra lỗi vừa gây ra sự tương tác kinh khủng của người dùng. Tôi muốn gửi tiền cho bạn của tôi John, không phải đến 0x234ag3453.

Công việc kinh doanh thực sự liên quan đến câu nói chuyên nghiệp: “Tôi sẽ cho bạn X $ nếu bạn cho tôi vé xem buổi hòa nhạc Y”. Chúng tôi hỗ trợ điều đó trực tiếp. Vì vậy, trong API của chúng tôi, khách hàng gọi các hợp đồng thông minh bằng cách tạo

 offer

S. Mỗi phiếu mua hàng nói lên những gì họ

 want

, họ sẽ làm gì

 give

cho, và trong những trường hợp nào họ có thể

 exit

với tài sản của họ. Các khoản thanh toán trong phiếu mua hàng đó sau đó sẽ tự đi vào khuôn khổ chứ KHÔNG phải hợp đồng thông minh. Cách duy nhất mà hợp đồng thông minh có thể nhận được nội dung là nếu nó cung cấp những nội dung mà đề nghị mong muốn.

Vì vậy, cung cấp an toàn trông như thế nào cho một cuộc đấu giá?

Zoe nắm giữ tất cả các tài sản và thông báo về hợp đồng của từng lời đề nghị. Khi phiên đấu giá kết thúc, hợp đồng đấu giá nguyên tử

 reallocates

vé hòa nhạc cho người trúng thầu và tiền của người thắng thầu cho người bán. Việc phân bổ lại đó sẽ chỉ thành công nếu giá trúng thầu là đủ cho người bán và nếu vé buổi hòa nhạc thực sự là giá mà người đặt giá thầu.

Không có hành vi sai trái, lỗi, v.v. nào trong hợp đồng đấu giá có thể cho phép nó lấy tiền từ những người đấu giá không nhận được vé xem buổi hòa nhạc.

Điều đó có nghĩa là khách hàng của cuộc đấu giá an toàn hơn RẤT NHIỀU. Họ không cần phải đọc mã đấu giá để biết rằng họ nhận được vé mong muốn hoặc số tiền của họ trở lại.

Ngoài ra, người tạo ra hợp đồng đấu giá cũng rất vui: nhiều mối nguy hiểm trong Solidity xoay quanh việc xử lý số tiền mà bạn không nên giữ. Thực sự đã có $ 1 tỷ + bị mất / bị đánh cắp do xử lý cẩu thả trong việc trả lại tiền từ các hợp đồng. Với Zoe và cung cấp sự an toàn, bạn không cần phải viết một dòng mã nào trong hợp đồng để giải quyết vấn đề đó một cách an toàn.

Một thuộc tính có liên quan là "khả năng thanh toán trực tiếp": hãy nhớ rằng mỗi khoản thanh toán đều có một

 exit

như một phần của các điều khoản của nó. Mặc định cho điều đó (mà bạn không cần phải chỉ định một cách thuận tiện) là “bất cứ khi nào tôi muốn; đó là tiền của tôi mang nó! “. Vâng, nó được gọi là “OnDemand” 🙂 Điều đó chỉ có nghĩa là bạn có thể thoát bất cứ khi nào bạn muốn, và một lần nữa, không có lỗi hoặc hành vi độc hại nào trong hợp đồng có thể trì hoãn việc bạn thoát khỏi phiếu mua hàng và lấy lại tài sản của mình. Tuy nhiên, lưu ý rằng “tài sản của bạn” có thể là sau khi một số phân bổ lại đã xảy ra. Nếu bạn đề nghị là "Tôi sẽ mua tối đa N vé cho X moola", thì có thể nó đã phân bổ lại một số N vé đó cho bạn và lấy tiền cho những vé đó, phù hợp với

 want

mà bạn đã chỉ định. Nhưng khi tín hiệu thoát của bạn xuất hiện, Zoe sẽ kéo tài sản của bạn và trả lại cho bạn mà không cần hợp đồng can thiệp. Tương tự, nếu hợp đồng bị treo, bị treo, v.v. Zoe sẽ thoát khỏi đề nghị của bạn. Thật đáng kinh ngạc khi số tiền vô tình bị “nhốt” trong các hợp đồng mà người dùng không có cách nào để lấy lại tiền của họ!

Dean Tribble, cảm ơn bạn rất nhiều vì câu trả lời chi tiết của bạn! Điều gì về các lỗ hổng hợp đồng thông minh? Làm thế nào chúng có thể được giảm bớt?

Dean Tribble Lời giải thích tuyệt vời !!

Để biết các cách giảm thiểu lỗ hổng hợp đồng thông minh, chúng tôi đã thảo luận

Các cách quan trọng bổ sung:

Trong Ethereum và các chuỗi khác (gần đây nhất là PolyNetwork), hàng tỷ khoản lỗ đến từ “sự tái nghiện”. Đó là nơi nếu có 2 thành phần (hoặc hợp đồng) A dự định gọi B và sau đó thực hiện điều gì đó X, nhưng B gọi lại thành a (nhập lại A) trước khi nó có thể đến X. Ví dụ: A là một cuộc đấu giá, một B yêu cầu hoàn lại tiền từ giá thầu. B nói “gửi cho tôi khoản tiền hoàn lại của tôi”, và vì vậy A tra cứu và gửi khoản tiền hoàn lại cho B, sau đó ghi lại rằng họ đã hoàn tiền cho B. NHƯNG khi B được gửi tiền hoàn lại, thay vì trả lời “cảm ơn”, nó ngay lập tức gửi lại thông báo “gửi cho tôi tiền hoàn lại” cho A. Vì A vẫn chưa ghi nhận rằng B đã nhận được tiền hoàn lại của mình, nên nó tiếp tục và gửi tiền hoàn lại một lần nữa . Và một lần nữa, B phản ứng với điều đó bằng cách "gửi tiền hoàn lại cho tôi". Dịch vụ A không bao giờ đạt đến điểm ghi rằng B đã nhận được tiền hoàn lại, vì vậy B chỉ làm điều này cho đến khi nó tiêu hết tài khoản của A. Nghe có vẻ xa lạ khi nói như thế này, nhưng đây chính xác là lỗi vào năm 2017 khiến mọi người tự hỏi liệu công nghệ đằng sau Agoric có thể giúp blockchain hay không. Và một lần khai thác 660 triệu đô la vào năm ngoái cũng là vấn đề cơ bản. Đó là bởi vì kiến trúc của Eth cho phép, hỗ trợ và thậm chí yêu cầu sự gần gũi.

Mô hình Agoric về cơ bản là không đồng bộ, có nghĩa là khi A gửi một thông điệp đến B, nó sẽ không ngồi đó chờ B làm điều gì đó. Nó tiếp tục và kết thúc việc ghi lại những gì nó cần ghi. Nó có nghĩa là ví dụ tầm thường không hoàn toàn tầm thường, nhưng nó cũng có nghĩa là ví dụ không tầm thường (như DeFi) không chứa đầy các mối nguy bảo mật.

Này Dean Tribble! Chào mừng bạn đến với chúng tôi! Bạn sẽ nói những thách thức chính khi xây dựng nền kinh tế ở DeFi là gì?

Ồ, tôi hiểu rồi. Cảm ơn vì đã giải thích, Dean Tribble. Sự xuề xòa có thể gây ra nhiều rắc rối. Có cách nào để biết khi nào chúng ta đang xử lý hệ thống gần đây nhất không?

cho thuê lại; nó là một phần của kiến trúc hệ thống, và do đó không thể được biên tập lại bằng các ngôn ngữ hoặc thư viện trợ giúp khác nhau. Một hệ thống trong đó các cuộc gọi giữa các hợp đồng hoặc các thành phần của hợp đồng là cuộc gọi trả lại (A gọi B và chờ câu trả lời) hầu như luôn luôn được sử dụng lại. Nếu trong khi A đang gọi cho B (“này, hãy hoàn lại tiền cho tôi”), một người khác có thể gọi vào A, thì có khả năng nó sẽ quay trở lại. Các kiến trúc không sử dụng thông điệp không đồng bộ (như agoric) hoặc chỉ có ngữ nghĩa hạn chế (như Kadena).

những thách thức trong việc xây dựng nền kinh tế ở DeFi

Dean Tribble, còn việc mở rộng quy mô web3 thông qua các nhà phát triển JavaScrip thì sao? Ý bạn là như thế nào? Có phải Agoric đang làm việc gì đó không?

Đó là trọng tâm của những gì chúng tôi đang làm việc. Nhiều người nói về việc mở rộng tốc độ giao dịch hoặc kích thước khối hoặc độ trễ. Nhưng điều khó nhất để mở rộng quy mô là cơ sở nhà phát triển. Để tiếp cận một cộng đồng các nhà phát triển lớn hơn đáng kể, chúng tôi không thể mong đợi rằng họ sẽ bỏ các ngôn ngữ và công cụ hiện tại của họ và làm việc trên một ngôn ngữ lập trình khác. Chúng ta phải “gặp họ ở nơi họ đang ở”.

Vì vậy, với agoric:

Các chi tiết cụ thể quan trọng (ví dụ: JavaScript với thực thi không đồng bộ, v.v.) nhưng cũng quan trọng là ưu tiên cho phép các nhà phát triển chỉ muốn hoàn thành một việc gì đó. Nền tảng của chúng tôi sẽ phát triển giống như JS và Node đã làm: ngay từ đầu vì nó cho phép các lập trình viên hoàn thành công việc! :)

Mục tiêu của tôi là “nếu bạn có thể xây dựng một ứng dụng web2 cho đám mây, bạn có thể xây dựng một ứng dụng web3 cho agoric”. Còn sớm, vì vậy chúng tôi vẫn chưa đến đó, nhưng chúng tôi sẽ đến.

Xin chào Dean Tribble, cảm ơn vì đã tham gia cùng chúng tôi! Câu hỏi của tôi là: tại sao mã nguồn mở? Mô hình này có những lợi ích và nhược điểm gì và làm thế nào để ưu hơn nhược điểm?

Rất nhiều lý do cho mã nguồn mở.

Động lực cá nhân: Tôi đã có cơ hội làm việc trong một số dự án tuyệt vời. Vấn đề là một số điều tuyệt vời nhất đã không xuất xưởng, và vì vậy, phần đó của cuộc đời tôi có một số niềm vui, thú vị, nhưng cuối cùng ít thời gian quý giá hơn nhiều. Phần lớn những gì chúng tôi đang làm cuối cùng là xây dựng một phiên bản mã nguồn mở của công nghệ thực sự hữu ích mà chúng tôi đã xây dựng trong nhiều phiên bản, nhưng không thể dễ dàng chuyển sang các dự án mới.

Động lực văn hóa: JavaScript là một thế giới mã nguồn mở phần lớn. Và chúng tôi muốn có nhiều thành phần có thể tái sử dụng. Về mặt lịch sử, kiểu tái sử dụng đó phát triển tốt nhất trong môi trường mã nguồn mở: các nhà phát triển biết rằng các nhà phát triển khác đều sử dụng cùng một ngăn xếp công nghệ cho các thành phần, vì vậy đó là nơi họ sẽ xây dựng và đóng góp các thành phần của mình.

Và cuối cùng: giá trị cốt lõi của blockchain là tính toàn vẹn cao thông qua phân quyền: các hợp đồng thông minh được thực thi trên nhiều máy tính do các nhà khai thác độc lập điều hành ở các khu vực pháp lý khác nhau. Nếu tất cả chúng đều chạy cùng một phần mềm mã nguồn đóng, thì về cơ bản chúng ta sẽ không có phân quyền. Những người thực hiện là một nguồn duy nhất của sự thất bại. Và thực sự nó cần phát triển thành mã do cộng đồng sở hữu. Điều đó chỉ thực sự hoạt động với mã nguồn mở.

Đó là một bọc! Cảm ơn bạn rất nhiều vì đã ở đây trả lời các câu hỏi của chúng tôi, Dean Tribble. Bạn có bất kỳ suy nghĩ cuối cùng nào hoặc có điều gì bạn muốn quảng cáo không?

Chúng tôi sẽ ra mắt “mainnet1” của mình để cung cấp mã thông báo ổn định được cộng đồng hậu thuẫn cho môi trường chuỗi liên kết. Hãy tham gia với cộng đồng tại http://agoric.com/discord và đăng ký nhận bản tin và http://agoric.com/newsletter ! Và nếu bạn là nhà phát triển web2, hãy kiểm tra endojs. Cảm ơn vì đã giúp tôi!

Và tất nhiên các kênh thông báo Agoric của chúng tôi,
Telegram ( https://t.me/agoric_ann ) và Twitter ( https://twitter.com/agoric ).