Tên lửa, mối đe dọa lượng tử, số 0 và số 1: Dean Little và hành trình tôi luyện chân lý của Solana

Giới thiệu

Blockchain được xây dựng trên những lời nói dối. Hay chính xác hơn là những lời nói dối lịch sự, thể hiện qua nhiều lớp trừu tượng. Thế giới mà nhà phát triển nhìn thấy tràn ngập SDK, API và framework hứa hẹn tốc độ cùng sự an toàn. Thực tế phức tạp hơn nhiều, đầy rẫy thanh ghi, syscall và bytecode—một thực tế mà chỉ những kẻ cuồng nhiệt mới dám đặt chân vào. Thực chất, mọi lớp trừu tượng đều tạo ra chi phí phụ và mọi trình biên dịch đều che giấu sự thật.

Dean Little đã dành cả sự nghiệp để tìm đường qua những lời nói dối này, truy tìm sự thật bằng cách hàn mạch và nạp EEPROM. Với Bitcoin, anh xây dựng các mining pool, kernel GPU và công cụ SPV, luôn ở gần cỗ máy nhất có thể, đồng thời khám phá tiềm năng của những hệ thống phân tán mà vào thời điểm đó chúng chưa bao giờ thực sự phát huy được. Rồi anh tìm thấy Solana, nơi anh nổi tiếng với những hành động bị xem là dị giáo: tự tay viết hợp ngữ, coi thường trình biên dịch và lạm dụng syscall—không phải vì vui, mà vì tốc độ là chân lý.

Với vai trò Nhà khoa học trưởng tại Zeus Network, anh đã triển khai toàn bộ giao thức Bitcoin từ đầu trên Solana, cho phép thanh khoản BTC lưu chuyển liền mạch. Và trong một màn phô diễn chống lại nỗi sợ hãi, bất định và nghi ngờ về lượng tử mà không ai có thể bắt bẻ, anh đã thiết kế một vault sử dụng Chữ ký Một lần Winternitz, có khả năng di chuyển hàng chục nghìn tài sản mỗi giây trong khi những người khác mới chỉ mơ đến con số sáu. 

Tuy vậy, Dean cũng là một người thầy. Từ Turbin3 đến Blueshift và công việc gần đây với vai trò DevRel cho nhóm Thị trường tiếng Quan Thoại và tiếng Quảng Đông tại Solana Foundation, anh đưa các nhà phát triển vào một thế giới mà phần lớn mọi người sẽ không bao giờ thấy. Anh đã dạy hàng trăm nhà phát triển đưa sản phẩm lên on-chain, thường bằng chính ngôn ngữ của họ và bắt đầu từ con số không. Anh luôn sống trong sự giằng co: dùng các lớp trừu tượng để kéo mọi người lên, rồi đẩy họ xuống gần cỗ máy hơn. 

Tôi muốn hiểu việc sống trong sự giằng co ấy có ý nghĩa gì—giữa giáo dục và thử nghiệm, giữa trừu tượng và hợp ngữ, giữa viết mã cho con người và viết lệnh cho máy móc. Cuộc phỏng vấn này xoay quanh cuộc đối thoại đó và ý nghĩa của việc trò chuyện trực tiếp với cỗ máy khi tất cả những người khác đều đang nói mà không thực sự chạm đến nó.

Cuộc trò chuyện này đã được biên tập và rút gọn để súc tích hơn. 

Phỏng vấn

Khởi nguồn và thế giới quan

Ichigo: Từ rất lâu trước Solana, anh đã sửa chữa phần cứng, nạp EEPROM và viết các hệ thống điều khiển nhúng cho tên lửa. Việc làm việc sát với phần cứng đến vậy—đúng nghĩa với mỏ hàn và firmware—đã định hình thế giới quan của anh với tư cách một người kiến tạo như thế nào?

Dean Little: Tôi học hàn từ khoảng năm mười tuổi. Tôi lớn lên cùng vi xử lý và vi điều khiển, sau đó chuyển sang phát triển web và ứng dụng di động trước khi gia nhập một startup tên lửa ở Na Uy.

Làm việc với các hệ thống nhúng trọng yếu cho nhiệm vụ dạy bạn một vài điều rất quan trọng. Đầu tiên là chú ý đến từng chi tiết—bởi nếu có thứ gì đó hỏng, mọi chuyện có thể trở nên cực kỳ tồi tệ rất nhanh. Thứ hai là sự đơn giản: các hệ thống đơn giản, nhanh và dễ hiểu thường tốt hơn những thứ quá phức tạp. Và thứ ba, bạn học được cách tư duy đối kháng. 

Với tôi, làm việc trên các hệ thống điều khiển ballast cho tên lửa đại dương đồng nghĩa với việc liên tục đặt câu hỏi: điều gì xảy ra nếu bộ điều khiển này hỏng? Làm thế nào để phát hiện lỗi? Chúng ta có phương án dự phòng nào? Nếu hệ thống điều khiển tư thế sai và ta tưởng mình đang hướng lên trong khi thực tế lại hướng xuống thì sao? Nó buộc bạn phải thiết kế cho tình huống thất bại, thay vì cho rằng mọi thứ sẽ luôn vận hành.

Một điều khác bạn học được là không mù quáng tin vào công việc của người khác. Điều đó áp dụng cho cả phần mềm lẫn phần cứng. Nhà sản xuất phần cứng thay đổi thông số kỹ thuật, bộ phận thu mua có thể vô tình mua nhầm linh kiện, và đột nhiên chẳng có gì hoạt động. Có quá nhiều thứ có thể xảy ra sai sót, và chỉ cần một lỗi nhỏ là đủ khiến toàn bộ hệ thống sụp đổ. Lối tư duy đó đã theo tôi từ đó đến giờ. 

Từ đó, sự nghiệp của anh nhanh chóng đưa anh đến với Bitcoin. Anh từng làm việc trên các mining pool, kernel GPU, công cụ SPV và sau đó là Twetch. Những năm làm việc với hạ tầng Bitcoin đã dạy anh điều gì về việc xây dựng hệ thống phân tán ở quy mô lớn và về những hạn chế của blockchain thời bấy giờ?

Tôi chuyển sang phát triển Bitcoin toàn thời gian vào khoảng năm 2017. Tôi xây dựng trên nhiều blockchain—Bitcoin, EOS và một vài blockchain khác phổ biến vào thời điểm đó. Với Bitcoin, ban đầu tôi chỉ sử dụng nó, nhưng khi phí tăng vọt, về cơ bản nó trở nên không thể dùng được. Đó là làn sóng người dùng phổ thông đầu tiên thực sự đổ vào crypto, và khi ấy tôi nhận ra rằng một khi phí tăng vọt, blockchain trở nên vô dụng.

Trải nghiệm đó khiến tôi suy nghĩ lại về cái gọi là “bộ ba bất khả thi về khả năng mở rộng”. Thành thật mà nói, đó là một vấn đề bịa đặt nhảm nhí. Ngay từ năm 2017, chúng ta đã có thể gửi ảnh 4MB đi khắp thế giới trong chưa đầy một giây. Thật vô lý khi tin rằng blockchain không thể mở rộng vượt quá các block 1MB. Giới hạn không nằm ở vật lý—mà nằm ở thiết kế. 

Do lớp cơ sở của Bitcoin bị giới hạn quá nhiều, bạn buộc phải đổi mới theo những cách khác. Cuối cùng, tôi nghiên cứu sâu Secp256k1 và xây dựng các giải pháp để ẩn kết quả thực thi trong chữ ký. Đó là một dạng tính toán có thể xác minh còn khá thô sơ, từ rất lâu trước khi ZK thực sự cất cánh.

Những năm đó dạy tôi rằng điều hành một công ty Bitcoin thực chất là điều hành một công ty hạ tầng. Giao thức Bitcoin có thể làm được nhiều điều, nhưng phần mềm node lại bị hạn chế. Mô hình UTXO rất phù hợp để song song hóa vì trạng thái được phân tách, khá giống các account Solana, nhưng lại rất tệ cho trạng thái dùng chung và lập chỉ mục. Ngược lại, mô hình account của Ethereum rất phù hợp với trạng thái dùng chung nhưng lại rất tệ cho việc song song hóa. Điều khiến tôi vỡ lẽ ở Solana là mô hình account phân tách—nó kết hợp khả năng song song hóa của UTXO với tính tiện dụng của mô hình trạng thái toàn cục của Ethereum.

Bài học lớn nhất tôi rút ra từ những năm đó là hệ thống thường xuyên gặp lỗi, vì vậy chúng nên được thiết kế để hỏng một cách có kiểm soát thay vì thảm khốc. Bạn đừng bao giờ đơn giản chấp nhận các giới hạn. Hãy tìm những cách sáng tạo mà chưa ai nghĩ đến để vượt qua chúng. Đó là triết lý tôi đã mang vào công việc của mình trên Solana.

Giờ đây, nhiều người trong cộng đồng Solana biết đến anh như người chuyên viết hợp ngữ và coi thường trình biên dịch. Tại sao anh vẫn làm việc sát với cỗ máy đến vậy? Tại sao không tập trung nhiều hơn vào việc cải thiện các lớp trừu tượng cấp cao, bởi đó là nơi phần lớn nhà phát triển sẽ xây dựng?

Trái với quan niệm phổ biến, tôi là người đóng góp cho Anchor, Pinocchio, Agave, Alpenglow—về cơ bản là mọi thứ. Tôi đã làm việc về mật mã học, SIMD và các program cấp thấp trên toàn bộ stack. 

Vấn đề lớn nhất với việc phát triển trên Solana là mọi thứ ngoài các program on-chain và hạ tầng đều hoàn toàn bị kiểm soát quyền truy cập. Gần như không thể để các PR của tôi được merge vào bất kỳ repo chính thức nào. Nhưng còn program on-chain ư? Tôi có thể làm bất cứ điều gì mà hệ thống vô tình cho phép. Ở đó không có gì cản được tôi. Nó không cần cấp quyền. Tôi cứ thế làm cho nó tốt hơn và đánh bại mọi giới hạn.

Vậy câu hỏi là, nếu nhìn vào công việc của tôi, chất lượng của nó và những gì tôi đã làm cho các program on-chain, rồi muốn điều tương tự diễn ra ở những lớp khác trong stack, thì hãy bắt đầu merge PR của tôi đi, haha.

Còn về hợp ngữ, nói thẳng ra là trình biên dịch làm việc quá tệ, và những người phát triển nó cũng chẳng khá hơn bao nhiêu. Họ chưa bao giờ thực sự dành thời gian lắng nghe khách hàng cuối cùng của mình, tức các nhà phát triển. Vì vậy, chúng tôi phải tự xây dựng một toolchain độc lập để giúp cuộc sống của chính mình dễ dàng hơn.

Đáng tiếc là phần lớn nhà phát triển chỉ ở mức tầm tầm. Không phải theo nghĩa xấu, nhưng họ không giống Cavey, tôi hay những cao thủ DeFi tại Ellipsis thực sự biết cách viết những thứ có hiệu năng cao. Chúng tôi là một nhóm nhỏ kỳ lạ gồm các nhà phát triển biết cách đẩy giới hạn của hệ thống ở cấp thấp nhất và cải thiện nó để những người khác sử dụng. 

Phản hồi của chúng tôi có thể cực kỳ giá trị, nhưng phần lớn thời gian nó không được xem trọng. Vì vậy, cuối cùng chúng tôi chỉ đổi mới trên những thứ không ai có thể ngăn mình đụng tới—đó là VM. Đó là lý do xét trên phương diện này, tôi luôn ở gần cỗ máy. 

Đổi mới và đóng góp kỹ thuật

Nói về việc làm việc trên nhiều phần khác nhau của stack—giữa Zeus, Jupiter và thời gian riêng—anh đã xây dựng và tích hợp một số primitive mật mã học tiên tiến. Xây dựng bất kỳ dạng mật mã học on-chain nào trên Solana vốn nổi tiếng là khó khăn. Tương lai của mật mã học trên Solana sẽ như thế nào? Và ngoài việc hét vào mặt mọi người để họ merge PR, haha, làm thế nào để giúp người khác dễ dàng xây dựng các primitive tiên tiến hơn?

Quan điểm của tôi là vài năm trước, chúng ta có cả loạt đội ngũ ZK xếp hàng để xây dựng trên Solana. Về cơ bản, chúng ta bảo họ rằng: “Ừ, nó sắp có rồi,” rồi Firedancer xuất hiện và nói: “Không, chúng tôi sẽ không merge thứ này,” thế là mọi thứ đều bị trì hoãn. Một số đội ngũ trong đó đã huy động vốn nhưng thực sự không thể vận hành doanh nghiệp vì không có các primitive mật mã học on-chain cần thiết, nên họ buộc phải chuyển sang nơi khác. Điều đó thực sự khắc nghiệt. Đối xử với nhà phát triển như vậy là sai. Khách hàng đầu tiên của giao thức là nhà phát triển—nếu không chăm lo cho họ, sẽ chẳng có gì được xây dựng, và khi đó người dùng phổ thông cũng không có gì để dùng. 

Vậy nên tôi nói, được thôi, tôi sẽ tự tìm cách. Tôi đã hack syscall khôi phục Secp256k1 và về cơ bản jailbreak toàn bộ đường cong. Giờ đây, bạn có thể thực hiện chữ ký Schnorr, cam kết Pedersen, Bulletproofs, phép nhân đường cong elliptic tùy ý, thậm chí cả địa chỉ Taproot đã tinh chỉnh, tất cả mà không cần bất kỳ thay đổi giao thức nào và chỉ tốn khoảng 25.000 CU. Đó là công việc của một người trong thời gian rảnh. Tôi đã phát hành nhiều giao thức mật mã học hơn Anza, đúng không? Hãy tưởng tượng điều gì có thể xảy ra nếu việc đó thực sự được khuyến khích. Hãy tưởng tượng nếu quá trình phát triển cởi mở hơn. 

Điều buồn cười là phần lớn mọi người thậm chí không nhận ra đây là một bước đột phá lớn đến mức nào. Tôi đến một hội nghị và kể cho vài người ở Arcium về thứ mình đã xây dựng. Họ sẽ nói kiểu: “Đỉnh thật.” Nhưng ngoài khoảng mười người thực sự hiểu crypto(mật mã học) ở cấp độ đó trên Solana, chẳng ai thực sự chú ý. 

Còn về Anza—họ là những người tốt, nhưng chỉ có một chuyên gia mật mã học là Sam Kim. Dù anh ấy khá giỏi, tôi cho rằng việc không ai khác ở Anza biết gì về mật mã học là một tín hiệu khá tiêu cực. Họ đã mời tôi làm người đánh giá cho bản nâng cấp Alpenglow. Tôi đánh giá mã của Sam và nhìn chung nó tốt, ý tưởng của anh ấy cũng hợp lý. Tôi cho rằng việc họ đón nhận và tận dụng kỹ năng của người khác là điều tốt. Nhưng cuối cùng, Anza có lẽ sẽ không bao giờ thực sự giỏi lĩnh vực này. Bạn cần nhiều công ty cạnh tranh, mỗi công ty có một số mảng giao thoa nhưng vẫn sở hữu chuyên môn riêng. Việc Anza cố làm mọi thứ là không hợp lý. Điều chúng ta thực sự cần là đa dạng hóa hoạt động phát triển lõi.

Anh có nghĩ đây chủ yếu là vấn đề văn hóa không? Chẳng hạn, Ethereum có những L2 hoàn toàn dành riêng cho ZK như ZKsync hay StarkWare. Có phải Solana đã gạt ZK sang một bên vì coi đó là thứ mơ hồ về khả năng mở rộng? Kiểu như chúng ta thà khai thác tối đa phần cứng, nên đó là trọng tâm cốt lõi—chúng ta sẽ mở rộng chain theo cách đó. Và mặc dù ZK không nhất thiết chỉ được dùng trên Solana cho khả năng mở rộng, nó đã bị gạt bỏ vì bị nhìn nhận như vậy, khiến ZK giờ rơi vào vị thế kỳ lạ?

Tôi cho rằng công cụ chưa tốt. Không có lấy một hướng dẫn về cách sử dụng nó. Blueshift sẽ bổ sung một số hướng dẫn—chúng tôi chỉ đang cố merge phần SIMD Little Endian. Sau khi merge xong, chúng tôi sẽ phát hành một template ZK dễ dùng, hiệu năng thực sự cao cùng một vài hướng dẫn, bởi chúng tôi muốn giúp mọi người dễ xây dựng và hiểu cách nó hoạt động hơn.

Vấn đề hiện tại là hành trình từ con số không đến Hello, World! trên Solana phi lý đến khó tin. Nếu bạn xem Sui, làm theo tài liệu trong năm phút là sẽ có một Hello, World! hoạt động được. Solana không có điều đó. Vậy nên đó là khác biệt giữa việc Mysten Labs tuyển khoảng 10 người hiểu mật mã học và Anza tuyển một người, đúng không?

Theo tôi, có một giả định rằng Solana Foundation cực kỳ thiếu hiểu biết kỹ thuật về gần như mọi thứ. Khái niệm công nghệ của họ chỉ vươn đến mức thương mại hóa, đúng không? Vượt qua mức đó, họ giao việc suy nghĩ về những điều này cho Anza. Quan niệm ở đây là nếu câu trả lời nói nó tốt, thì hẳn nó phải tốt. Thực tế trong phần lớn trường hợp, câu trả lời là nó có hiệu năng tốt, nhưng không tốt lắm ở bất kỳ khía cạnh nào khác.

Foundation mặc định rằng mọi thứ đang diễn ra rất tốt. Nhưng trải nghiệm của nhà phát triển lại là: “Nó khó dùng.” Điều đó đau đớn khủng khiếp với những người giỏi hơn cả những người triển khai mọi thứ ở cấp giao thức, những người làm công việc không công nhưng lại không thể khiến công sức của mình được xem trọng. Kiểu như: “Ồ, tôi không biết nữa, họ không có huy hiệu Anza thần kỳ, hãy phớt lờ họ để khỏi phải chịu rủi ro danh tiếng hay merge PR từ cộng đồng.” Vậy nên tôi đoán đó là lý do mọi người có thể nhận thấy tôi đấu tranh quyết liệt và lên tiếng rất nhiều cho các nhà phát triển mã nguồn mở—để chúng ta có thể loại bỏ tình trạng này, bởi tôi cho rằng cộng đồng có rất nhiều người tạo ra những PR thực sự tốt. Chắc chắn có rất nhiều nội dung AI rác rưởi và rất nhiều thứ tệ hại, nhưng cũng có rất nhiều người thực sự giỏi xứng đáng được quan tâm. Đây là một blockchain, một mạng phân tán—chúng ta không nên cần một loại huy hiệu Anza nào đó mới được đóng góp. Họ chỉ nên có trách nhiệm quan tâm đến mã tốt, bất kể có phải do họ viết hay không.

Bất chấp tất cả những điều này, nói sâu hơn về đổi mới và mật mã học, anh cũng đã xây dựng một vault kháng lượng tử trên Solana bằng Chữ ký Một lần Winternitz. Điều gì đã truyền cảm hứng cho dự án đó, và anh hình dung nó sẽ phát triển thế nào trong tương lai, có lẽ khi các mối đe dọa lượng tử trở nên đáng tin hơn?

Thành thật mà nói, nó bắt đầu từ một tweet, haha. Cuối năm ngoái, một Bitcoin maxi đăng bài rằng: “Solana sẽ là nạn nhân đầu tiên của lượng tử.” Tôi đọc xong và nghĩ: “Được thôi, ông bạn. Nếu một ngày chúng ta cần di chuyển người dùng từ mật mã học không an toàn trước lượng tử sang mật mã học an toàn trước lượng tử, chain của chúng tôi có thể xử lý hơn 50.000 lượt di chuyển mỗi giây. Chain của ông làm được khoảng sáu. Vậy ai mới thực sự bị hạ gục trước?”

Thế là tôi nói, kệ mẹ nó, tôi sẽ biến điều đó thành hiện thực. 

Mười ngày sau, tôi tung ra Winternitz vault và trích dẫn tweet của ông ta, kiểu: GG. 

Đó là động lực—có người nói rằng việc đó không thể thực hiện được. Tôi đã suy nghĩ về các cơ chế chữ ký hậu lượng tử được một thời gian, nhưng điều đó khiến tôi quyết tâm hành động.

Và nó đã hoạt động. Bạn có thể lưu trữ tiền trong một PDA nằm ngoài đường cong, sử dụng Winternitz vault, và bất kể điều gì xảy ra—dù ledger bị rollback hay các cuộc tấn công lượng tử gây rối chữ ký của leader—ít nhất trong bất kỳ phiên bản nào chúng ta rollback về, tiền của bạn vẫn an toàn. Đây không phải giải pháp triệt để, nhưng là một chiếc bè cứu sinh hoàn hảo. 

Nếu bạn là nhà quản lý quỹ nắm giữ hàng triệu hoặc hàng tỷ đô la LST hay SOL đã stake, và đột nhiên khả năng an toàn trước lượng tử trở thành yêu cầu pháp lý, thì đây không còn là rào cản đối với việc áp dụng. Bạn không cần nâng cấp giao thức. Nó cứ thế hoạt động.

Hiện tại, tôi đã xây dựng firmware Ledger có thể tạo các chữ ký này, cùng với một ví và ứng dụng web. Blueshift có thể sẽ phát triển nó thành thứ thân thiện hơn với người dùng vào cuối năm nay. Rõ ràng đây chưa phải việc cấp bách, nhưng điểm mấu chốt là: lựa chọn này đã tồn tại ngay hôm nay. Đó chính là bước đột phá.

Thực ra chuyện này rất buồn cười. Ngày hôm sau Toly nhắn tin riêng cho tôi. Anh ấy đùa rằng: “Ông bạn, tôi cứ nghĩ khi máy tính lượng tử xuất hiện, tôi sẽ phải âm thầm nghỉ hưu.” Tôi đáp: “Haha, không đâu ông bạn, đừng nghỉ hưu. Bọn tôi lo được.”

Nhắc đến Bitcoin, anh là Nhà khoa học trưởng tại Zeus Network, nơi về cơ bản anh đã triển khai toàn bộ giao thức Bitcoin từ đầu trên Solana. Những thách thức lớn nhất để đạt được điều đó là gì? Và anh có hình dung một tương lai nơi các chain khác cũng được tái triển khai trên Solana không?

Đó là một câu hỏi cực kỳ thú vị. Tương tự như chữ ký Winternitz vốn đòi hỏi lượng tính toán cực lớn nhưng vẫn vừa đủ để thực hiện trong một transaction duy nhất, Bitcoin cũng nằm trong điểm cân bằng lý tưởng đó. Nó đủ tinh vi để chúng ta có những thứ như bằng chứng SPV, nhưng vẫn đủ nguyên thủy để Solana, một nền tảng tiên tiến hơn với hiệu năng cao hơn, có thể lấy thứ đó và đặt vào trong thứ này.

Với các blockchain thế hệ thứ hai như Ethereum, mọi thứ phức tạp hơn. Chúng ít nguyên thủy hơn nhiều và phức tạp hơn hẳn. Vì vậy, câu hỏi trở thành: Solana có thể tiếp tục nhanh hơn, đồng thời phân bổ ngày càng nhiều tài nguyên cho từng transaction không? 

Hiện tại việc này vẫn khó, dù không phải bất khả thi. Thứ chủ yếu còn thiếu để tương thích EVM ngày nay là syscall BigModExp. Nếu kích hoạt nó, tôi cho rằng chúng ta có thể tiến khá gần đến mức tương đương hoàn toàn với Ethereum ở cấp VM, và nghĩ đến điều đó cũng khá điên rồ. 

Tuy nhiên, câu hỏi lớn hơn là: tại sao phải bận tâm? 

Với Bitcoin, câu trả lời rất rõ ràng: nó có giá trị hàng nghìn tỷ đô la, là chuẩn vàng của tiền tệ và đủ nguyên thủy để Solana có thể sao chép một cách gọn gàng. 

Ethereum thì không hẳn. 

“Tiền siêu âm” là một meme. Trong một khoảnh khắc ngắn, ngân sách bảo mật của Solana thực sự đã vượt qua Ethereum, vậy điều đó có biến Solana thành tiền siêu âm không? Việc bọc ETH lên Solana không tạo thêm nhiều giá trị bằng việc bọc BTC.

Vậy nên đúng, tôi cho rằng Bitcoin là mục tiêu đầu tiên phù hợp. Nó khả thi về mặt kỹ thuật và có ý nghĩa về mặt kinh tế. Khi Solana tiếp tục cải thiện, cuối cùng chúng ta có thể thấy các chain khác cũng được tái triển khai. Nhưng thành thật mà nói, Solana càng có hiệu năng cao thì càng ít cần phải bận tâm đến các chain khác.

Khả năng gói toàn bộ chức năng này vào một transaction duy nhất thực sự rất thú vị. Gần đây, anh bị cuốn vào bài toán cập nhật oracle siêu hiệu quả, đẩy giới hạn với Doppler và những bản cập nhật chỉ tốn 21 CU. Những thành tựu CU thấp này thể hiện lợi thế của Solana so với các chain khác như thế nào? Chúng ta đã thấy những phát triển tương tự trên các chain khác với việc tối ưu gas, nhưng Solana mở ra những khả năng độc đáo nào?

Oracle là một trường hợp nghiên cứu thực sự thú vị vì mọi người đều có xu hướng xem nó là vấn đề “đã được giải quyết”. 

Nếu nhìn lại khoảng một tháng trước, Cavey đã dùng program noop của tôi và đạt 100.000 transaction mỗi giây trên mainnet. Điều đó rất tuyệt. Giờ chúng tôi sẽ xem liệu có thể đẩy xa hơn nữa không. Cụ thể hơn là 100.000 lượt cập nhật oracle mỗi giây trên mainnet. 

Nếu điều đó khả thi, nó sẽ hoàn toàn phá tan luận điểm “chúng ta cần thời gian block nhanh hơn để cạnh tranh với Binance”. Ý tôi là, nếu có thể cập nhật oracle một trăm nghìn lần mỗi giây, ai còn quan tâm đến những bản cập nhật 20 mili giây của Binance?

Đó chính là mục đích của việc siêu tối ưu hóa. Prop AMM đã sử dụng một kiểu cập nhật tương tự—không hoàn toàn giống thứ tôi đang công bố, nhưng ai hiểu thì sẽ hiểu. Hiện tại, họ đang nhúng logic đó sâu vào các chiến lược giao dịch của mình. 

Với Doppler, không có nhiều lý do để giữ sự phức tạp đó bên trong các program của họ. Phần cập nhật oracle có thể được tách hoàn toàn và chạy độc lập.

Dung lượng cũng cực kỳ nhỏ. Oracle Doppler chỉ khoảng 480 byte. Tôi thậm chí còn đang phát triển một SDK TypeScript để các nhà phát triển có thể triển khai phiên bản tùy chỉnh của riêng mình trực tiếp từ TypeScript mà không cần chạm vào Rust. Bạn chỉ cần định nghĩa schema Borsh, phát hành nó và có thể bắt đầu cập nhật oracle hết tốc lực. Rõ ràng các nhà phát triển Rust cũng có thể làm điều tương tự, nhưng tôi thấy thật thú vị khi giờ đây ngay cả một nhà phát triển TypeScript cũng có thể tiếp cận mức hiệu năng đó nhờ hợp ngữ được siêu tối ưu hóa ở bên dưới.

Về trường hợp sử dụng: oracle tạo số ngẫu nhiên, hợp đồng vĩnh cửu, oracle AMM, prop AMM—tất cả đều được hưởng lợi. Ngoài ra còn có những thứ như kênh thanh toán hoặc mở rộng L2. Nếu có thể mở và đóng kênh với chi phí gần như bằng không, đó là một bước tiến lớn. Về cơ bản, bạn không còn cần một program Anchor khổng lồ, nặng nề chỉ để cập nhật oracle. 

Trừu tượng, hợp ngữ và IBRL

Với danh tiếng là người chuyên viết hợp ngữ, anh có nghĩ phần lớn nhà phát triển thực sự nên động đến nó không? Hay đây là một trong những trường hợp chỉ cần một vài người đẩy giới hạn để những người còn lại có thể an toàn xây dựng ở những tầng cao hơn của stack?

Tôi nghĩ mọi người đều nên học nó, ít nhất là một chút. George Hotz, có lẽ là lập trình viên giỏi nhất còn sống, có một câu rằng mọi người đều nên học Python, C và hợp ngữ. 

Nếu không hiểu hợp ngữ, bạn sẽ không hiểu trình biên dịch thực sự đang làm gì. Nếu không hiểu C, bạn sẽ không trân trọng mọi tiện ích mà Python mang lại. Tôi không cho rằng Python tuyệt vời đến vậy, nhưng chẳng hạn Rust là một ngôn ngữ có khả năng biểu đạt rất cao và có thể dùng ở cả cấp cao lẫn cấp thấp. Đó là lựa chọn tuyệt vời.

Vậy nên đúng, tôi sẽ khuyên học một ít hợp ngữ và Rust. Đến một lúc nào đó, bạn cũng sẽ cần học TypeScript nếu muốn viết frontend. Cuối cùng, bạn đang xây dựng sản phẩm cho con người, và nếu người dùng của bạn là nhà phát triển, TypeScript sẽ lọt vào tầm ngắm dù bạn có thích hay không.

Khi tôi bắt đầu viết hợp ngữ trên Solana, thực sự không có ai làm điều đó. Tôi đã xây dựng công cụ, đưa ra các ví dụ, và giờ có vài trăm người đã thử. Có lẽ khoảng mười người thực sự giỏi. Một số thậm chí đã viết những program ấn tượng hơn cả tôi. Chủ yếu chỉ là dành thời gian để biến nó thành hiện thực.

Phần lớn những gì tôi làm đều nhỏ gọn, thanh lịch, siêu hiệu quả và chỉ phục vụ một mục đích—ở những nơi tôi thấy tiềm năng giảm 100 lần chi phí thực thi. Vai trò của tôi thiên về khám phá, truyền cảm hứng và để người khác đưa nó tiến xa hơn. Ở giai đoạn này, việc tự quảng bá mọi thứ mình xây dựng không mang lại nhiều lợi ích, nên tôi muốn làm nổi bật người khác, đăng lại bài của họ và giúp họ tạo dựng tên tuổi hơn.

Vì vậy, đúng, tôi nghĩ ít nhất mọi người đều nên học hợp ngữ. Đó là một bài tập tuyệt vời. Nhưng đồng thời, đúng là một nhóm nhỏ quyết liệt đẩy giới hạn ở cấp thấp nhất có thể tạo ra những cải tiến mang lại lợi ích cho tất cả mọi người. 

Nếu nhìn vào phần lớn các cải tiến của Pinocchio trong sáu tháng qua, tất cả đều đến từ việc tối ưu hóa hợp ngữ. Febo đã phân loại từng PR một như một cao thủ thực thụ và giúp merge được một số thứ thực sự tốt. Hãy nhìn p-token—đó cũng là cùng một khái niệm. 

Anh có xem việc lập trình cấp thấp không chỉ là một lựa chọn kỹ thuật mà còn mang tính hệ tư tưởng không?

Có, tôi nghĩ nó là cả hai. Chẳng hạn, tại sao mọi người muốn đưa một ảnh JPEG lên Bitcoin? Việc dùng một hệ thống thực sự hạn chế cho mục đích mà nó chưa bao giờ được thiết kế để thực hiện có điều gì đó nguyên thủy và hấp dẫn về bản chất. Nó vừa buồn cười lại vừa đẹp đẽ. 

Sự tò mò kết thúc khi bạn ngừng đặt câu hỏi. 

Vì vậy, nếu là một người tò mò, điểm đến hợp lý của sự tò mò có lẽ sẽ là những câu hỏi như: “Tôi đã viết một thứ bằng TypeScript sử dụng một program Anchor. Anchor hoạt động như thế nào? Macro hoạt động ra sao? Rust hoạt động thế nào? Hợp ngữ hoạt động ra sao?” 

Sau đó, có lẽ bạn bắt đầu nghiên cứu sâu trình biên dịch Rust, rồi MIR, LLVM IR và cách nó được biên dịch thành eBPF. Tiếp đó, bạn hỏi eBPF là gì và đọc về hợp ngữ của nó. Cuối cùng, bạn nhìn chằm chằm vào bytecode thô và nhận ra mình có thể cắt giảm vài byte vì trình biên dịch không tự động tối ưu hóa một thứ nào đó. Đó là điểm đến hợp lý của hành trình tìm hiểu. Chắc chắn có một khía cạnh hệ tư tưởng trong đó.

Anh cũng đang làm việc với Solana Foundation, giúp các đội ngũ nói tiếng Quan Thoại và tiếng Quảng Đông gia nhập, gỡ lỗi và xây dựng. Anh làm việc với tất cả các đội ngũ này, giúp họ bằng cách khiến mọi thứ đơn giản và dễ tiếp cận hơn. Đồng thời, anh nổi tiếng vì cổ xúy hợp ngữ và lạm dụng syscall. Anh dung hòa sự giằng co đó như thế nào? Làm sao anh cân bằng giữa việc đưa nhà phát triển đến gần phần cứng hơn và nhu cầu thực tế là giúp họ bắt đầu thông qua các lớp trừu tượng cấp cao?

Nếu nhìn vào Blueshift, về cơ bản chúng tôi đã thiết kế một lộ trình liên tục từ người mới bắt đầu đến chuyên gia. Quan điểm của tôi rất đơn giản: bạn sẽ có được đội ngũ nhà phát triển tương ứng với cách mình đào tạo. Nếu chỉ dạy Anchor hoặc TypeScript, bạn chỉ thu hút kiểu nhà phát triển cho rằng như vậy là đủ. Nhưng nếu bắt đầu nói về việc cắt giảm từng đơn vị tính toán bằng hợp ngữ tự viết, bạn sẽ thu hút một tầng nhà phát triển khác—những người thực sự hiểu các từ đó có nghĩa gì.

Chiến lược của chúng tôi với Blueshift là trước tiên nhắm vào phần giữa của đường cong. Đó là nơi có số lượng lớn và mang lại ROI tốt nhất. Sau đó, chúng tôi đưa họ dần sang phải, giúp họ nâng cao trình độ, và cuối cùng bạn sẽ có một đội quân nhà phát triển mạnh có thể quay lại hỗ trợ phía bên trái đường cong—những người hoàn toàn mới.

Cách đó đơn giản là dễ mở rộng hơn. Tôi có thể dành hàng giờ mỗi ngày để dạy người mới cách CPI vào Token Program, vốn chiếm 90% tổng số program Solana. Hoặc tôi có thể đào tạo một trăm người làm điều tương tự, rồi mỗi người trong số họ lại có thể hướng dẫn thêm một trăm người nữa. Đó là cách bạn mở rộng. 

Chúng tôi muốn đón nhận mọi người ở bất kỳ trình độ nào và tiếp tục đưa họ tiến sang bên phải. Blueshift, Solana Foundation—tất cả đều hướng đến cùng một mục tiêu.

Giáo dục, chuyển giao tri thức và cộng đồng

Nhắc đến Blueshift, anh đã đồng sáng lập dự án này cùng với Turbin3, cả hai đều có sứ mệnh giáo dục mạnh mẽ. Anh hình dung những sáng kiến này sẽ phát triển thế nào trong tương lai? 

Turbin3 chưa có nhiều thứ khi tôi gia nhập. Tôi tham gia, viết tất cả program trong chương trình học và bắt đầu vận hành mọi thứ. Tôi nghĩ mình đã tổ chức ba hoặc bốn khóa và đào tạo tất cả những người hiện đang làm giảng viên. Trong vòng chín tháng, từ con số không đến việc có thể thay thế chính mình bằng hoạt động đào tạo tốt, không còn nhiều việc để tôi làm. Việc đào tạo ra những người có khả năng đào tạo tốt cho thấy ở đây tồn tại một hiệu ứng bánh đà có thể mở rộng.

Vấn đề là mỗi quý họ nhận được một nghìn hồ sơ và từ chối khoảng 800 đến 900 người. Những người được nhận sẽ trải qua một khóa sáu tuần, trong đó họ phải đến lớp ba lần mỗi tuần. Khi kết thúc, họ không nhận được chứng chỉ hay bất kỳ thứ gì chứng minh mình đã tốt nghiệp—có thể họ sẽ xác nhận năng lực cho bạn, cũng có thể không. Nhưng sáu tuần là khoảng thời gian dài để không có gì trục trặc trong cuộc sống. Chó của bạn có thể bị ốm, bạn phải đưa nó đến bác sĩ thú y và bỏ lỡ vài buổi học, rồi đột nhiên bạn bị tụt lại và bị loại. Các bootcamp truyền thống tốn rất nhiều thời gian và tiền bạc để vận hành, đồng thời chúng không thực sự tối ưu cho những nhà phát triển giỏi nhất. Hoặc bạn đang giúp những người vốn không thực sự cần bootcamp và chỉ cần một điểm khởi đầu cho sự nghiệp, hoặc có lẽ bạn đang dìu dắt sát sao những người không thể hoàn thành nếu thiếu sự hỗ trợ liên tục đó. Cả hai con đường đều không thực sự mở rộng việc tiếp nhận nhà phát triển theo cách Solana cần hiện nay.

Vì vậy, câu hỏi hay hơn là: làm thế nào để tiếp cận 800 đến 900 người bị các bootcamp từ chối và trao cơ hội cho những người thực sự có năng lực? 

Với Blueshift, câu trả lời là xây dựng nội dung tự học chất lượng cao. Nếu có thể theo kịp tài liệu, bạn có thể hoàn thành theo lịch của riêng mình và nhận NFT để chứng minh. Mọi thứ đều là mã nguồn mở, và chúng tôi chủ động khuyến khích pull request từ cộng đồng, đồng thời giới thiệu mọi người trên Twitter để giúp quảng bá và tạo đà cho sự nghiệp của họ. Mọi người gửi các cải tiến, chúng tôi merge chúng và toàn bộ nền tảng trở nên tốt hơn.

Thay vì nói: “Rất tiếc, bạn không được nhận, lần sau chúc may mắn,” chúng tôi nói: “Đây là chương trình học, hãy tự chinh phục nó theo lịch của bạn.” Chúng tôi đã có bài học được dịch sang tám ngôn ngữ, nên mọi người có thể tổ chức meetup hoặc bootcamp ở bất cứ đâu trên thế giới. Superteam có thể sử dụng nó. Forma có thể sử dụng nó. Cuối cùng, bạn có một tiêu chuẩn khách quan: mọi người nhận được cùng một NFT, bạn biết trình độ của họ và có thể tuyển dụng hoặc đưa ra thử thách tương ứng.

Blueshift giải quyết tất cả những vấn đề này bằng cách tập trung vào các nhà phát triển có động lực và đủ năng lực theo đuổi nội dung tự học chất lượng cao. Chúng tôi chấp nhận thực tế rằng nếu mở mã nguồn mọi thứ, mọi người sẽ phê bình kỹ hơn và nhờ đó trí tuệ của cộng đồng sẽ tỏa sáng. Vì vậy, chúng tôi merge PR của họ và cuối cùng có được nền tảng giáo dục cùng nội dung tốt nhất hiện nay.

Về cơ bản anh đã ngầm trả lời câu hỏi này, nhưng để nói rõ hơn: Anh xem giáo dục nhà phát triển chủ yếu là bài toán chuyển ngữ—giúp các ý tưởng phức tạp trở nên dễ tiếp cận hơn—hay bài toán bootcamp—nhanh chóng đưa nhiều người đạt trình độ nền tảng, hay là một vấn đề hoàn toàn khác?

Đúng vậy, vấn đề chính của giáo dục nhà phát triển hiện nay là những tài nguyên miễn phí mà chúng ta cung cấp quá tệ. Phần lớn đã lỗi thời. Về cơ bản, mọi người đều viết bằng Anchor hoặc Pinocchio. Không ai dùng solana_program. Mọi thứ lỗi thời rất nhanh. Vì vậy, khi mọi thứ đều là mã nguồn mở, chúng tôi có thể nhanh chóng và tỉ mỉ tạo ra nội dung tốt rồi duy trì nó. Có vẻ không ai khác thực sự muốn làm việc này, nên chúng tôi sẽ làm vì chẳng ai khác muốn làm. 

Ngay cả Mert cũng nhận ra điều này sáu tháng trước khi chúng tôi thảo luận về nó. Từ góc nhìn của mình, anh ấy vui vì có người quyết định quan tâm đến vấn đề này. Và ai phù hợp hơn chúng tôi chứ, đúng không? Tôi may mắn là một trong những nhà phát triển có ảnh hưởng lớn hơn trong lĩnh vực này. Mọi thứ đều là mã nguồn mở. Chúng tôi không có hào phòng thủ, haha. Chúng tôi không có khoản tài trợ khổng lồ từ Foundation—chúng tôi tự cấp vốn. Chúng tôi tự làm tất cả, và hào phòng thủ duy nhất của chúng tôi là khả năng thực thi. 

Giáo dục là một quá trình liên tục. Bạn cần gặp mọi người ở đúng trình độ của họ với những nội dung đủ thách thức để họ học được điều gì đó, nhưng cũng đủ dễ hiểu và dễ tiếp cận để họ tiếp tục quay lại. Sau đó, bạn bắt đầu cuốn họ sang bên phải bằng những bài toán hấp dẫn. Tôi nghĩ mình làm tốt việc đó, nên Blueshift là nền tảng tối thượng để cuốn dân kỹ thuật vào các bài toán. Rồi đột nhiên bạn tự hỏi: “Cái quái gì vậy? Sao giờ mình lại đang viết hợp ngữ?” 

Discord của Blueshift cũng cung cấp dịch vụ DevRel để giúp mọi người phát triển dự án khi họ gặp khó khăn. Điều quan trọng nhất là tôi thậm chí không trả lời phần lớn câu hỏi trong đó—cộng đồng làm việc đó. Và nó tốt hơn nhiều so với StackOverflow hay những nơi tương tự vì bạn có một cộng đồng mạnh mẽ và tích cực tham gia.

Tương lai của Blueshift sẽ như thế nào?

Tương lai của Blueshift về cơ bản là hai sản phẩm: Coursera và LeetCode. Chúng tôi đã có phiên bản tạm ổn—à, tốt hơn mức ổn nhưng chưa lý tưởng—của hai sản phẩm này, nhưng chúng cần phải tốt hơn. Chúng tôi đang phát triển V3, nên mọi thứ sẽ được cải thiện rất nhiều. 

Chúng tôi muốn đạt hiệu quả cực cao trong việc phục vụ những nhà phát triển có khả năng theo đuổi nội dung tự học. Và thành thật mà nói, đó là kiểu nhà phát triển tôi muốn có trong hệ sinh thái hơn. 

Tôi muốn những người cứ xắn tay áo lên và bắt tay vào làm. Chúng tôi muốn giúp họ làm điều đó dễ dàng nhất có thể bằng cách cung cấp tài nguyên tốt. Vì vậy, đừng lãng phí thời gian của họ bằng những thứ lỗi thời với dependency bị hỏng và đủ loại vấn đề khác. 

Mục tiêu cuối cùng là có một nền tảng nơi mọi người có thể học điều mình quan tâm mà không bị đóng khung, rồi chứng minh năng lực bằng cách hoàn thành các thử thách khác nhau. 

Câu hỏi nhanh

Gần đây anh nghe nhạc gì khi viết hợp ngữ?

Haha, thường là death metal.

Syscall nào đáng để lạm dụng nhất trên Solana?

secp256k1_recover

Nếu phải chọn, anh muốn viết C# hay Java trong suốt phần đời còn lại?

Không.

Mô hình nào tốt hơn: dựa trên UTXO hay dựa trên account?

Một UTXO đáng giá hơn.

Nếu có nguồn lực không giới hạn, sáng kiến giáo dục trong mơ nào anh sẽ triển khai ngay ngày mai?

Blueshift cộng với IRL. 

Một lời khuyên để dạy các khái niệm Solana cấp thấp cho nhà phát triển mới mà không khiến họ sợ hãi là gì?

Hài hước tự trào.

Kết luận

Trong một thế giới của những lớp trừu tượng cấp cao và việc chấp nhận chúng như “thực tế” để thu hút số đông, Dean Little là một cây cầu hiếm có—một nhà giả kim cấp thấp rèn công cụ từ những yếu tố cơ bản nhất để nâng người khác lên vai mình. Hành trình từ tên lửa đến việc phổ biến các bản cập nhật oracle siêu tối ưu của anh cho thấy đặc tính của một người kiến tạo. Một đặc tính không khoan nhượng trong hành trình truy tìm chân lý: thiết kế cho thất bại, đổi mới để vượt qua giới hạn và đừng bao giờ mù quáng đặt niềm tin vào bất kỳ điều gì.

Dù anh đang dùng ý chí biến các vault lượng tử thành hiện thực hay mở rộng Blueshift để cuốn thế hệ nhà phát triển Solana xuất chúng tiếp theo vào những bài toán kỹ thuật (hy vọng họ có thể đứng trên vai những người khổng lồ và không phải nhai nhiều mảnh kính như phần còn lại của chúng ta), Dean hiện thân cho ngọn lửa của người theo chủ nghĩa thuần túy, được tôi luyện bởi sự ấm áp của cộng đồng. Đó là lời nhắc rằng tiến bộ thực sự không chỉ là ném thêm củi vào lửa, xếp hết lớp này lên lớp khác—mà là bóc ngược những lớp đó để hé lộ tiếng rì rầm của máy móc và dạy người khác cách hòa nhịp cùng nó.

Khi Solana lao về phía bước nhảy vọt tiếp theo, dù đó là khả năng tương đương hoàn toàn với EVM, Alpenglow hay 100.000 lượt cập nhật oracle mỗi giây, công việc của Dean khẽ gửi đến tất cả chúng ta một lời thách thức: Tại sao phải chấp nhận những lời nói dối lịch sự khi bạn có thể tự hàn nên thực tại của mình? Nếu sự tò mò là tia lửa, thì những người như Dean chính là chất xúc tác.

Hãy lao vào, lạm dụng một syscall, nhồi đầy một transaction bằng các chức năng phức tạp, và ai biết được—có thể bạn sẽ bước ra với chiếc bè cứu sinh lượng tử của riêng mình.