Giới thiệu lần đầu về TON: Tài khoản, Token, Giao dịch và Bảo mật Tài sản

avatar
慢雾科技
3tháng trước
Bài viết có khoảng 5196từ,đọc toàn bộ bài viết mất khoảng 7 phút
Bài viết này sẽ thảo luận về các đặc điểm của TON và các vấn đề bảo mật tài sản người dùng từ góc độ tài khoản, mã thông báo và giao dịch.

Tác giả gốc: Johan

lý lịch

TON (Mạng mở) là một nền tảng blockchain phi tập trung được thiết kế và phát triển ban đầu bởi nhóm Telegram. Mục tiêu của TON là cung cấp nền tảng blockchain hiệu suất cao và có thể mở rộng để hỗ trợ các ứng dụng phi tập trung (DApps) và hợp đồng thông minh quy mô lớn.

TON rất đặc biệt, dễ sử dụng, được tích hợp sâu với Telegram, giúp người bình thường dễ dàng sử dụng token; nó cũng phức tạp, nó có kiến trúc hoàn toàn khác với các blockchain khác và nó sử dụng FunC không chính thống. Ngôn ngữ hợp đồng thông minh. Hôm nay chúng ta thảo luận về các đặc điểm của TON và các vấn đề bảo mật tài sản người dùng từ góc độ tài khoản, mã thông báo và giao dịch.

Đặc điểm của TON

Tạo tài khoản

Địa chỉ tài khoản TON được tạo khác với hầu hết các blockchain. Đó là địa chỉ hợp đồng thông minh. Đầu tiên, tạo khóa riêng TON chủ yếu sử dụng thuật toán Ed 25519 để tạo khóa chung như sau:

Giới thiệu lần đầu về TON: Tài khoản, Token, Giao dịch và Bảo mật Tài sản

Có hai dạng khóa chung. Một là khóa chung ban đầu được tính từ khóa riêng, có dạng như sau:

E39ECDA0A7B0C60A7107EC43967829DBE8BC356A49B9DFC6186B3EAC74B5477D

Cái còn lại là khóa chung được làm đẹp, mang một số thông tin và chữ số kiểm tra của khóa chung, dưới dạng: Pubjns2gp7DGCnEH7EOWeCnb6Lw1akm538YYaz6sdLVHfRB2

Sẽ là quá ngây thơ khi nghĩ rằng bạn có thể lấy địa chỉ tài khoản giống như Ethereum bằng cách lấy khóa chung. Chỉ cần có khóa chung của người dùng là không đủ để tính địa chỉ tài khoản của người dùng. Chúng tôi vừa nói rằng địa chỉ tài khoản của người dùng là địa chỉ hợp đồng thông minh, nhưng chúng tôi thậm chí không có tài khoản. Làm cách nào để triển khai hợp đồng thông minh? Trình tự đúng là trước tiên phải tính địa chỉ, nhận số lượng token ban đầu và sau đó bạn có thể triển khai hợp đồng. Quá trình tính toán địa chỉ tài khoản được thể hiện trong hình dưới đây:

Giới thiệu lần đầu về TON: Tài khoản, Token, Giao dịch và Bảo mật Tài sản

Địa chỉ của người dùng cũng có nhiều dạng. Đầu tiên là dạng gốc, trông giống như:

0:b4c1b2ede12aa76f4a44353944258bcc8f99e9c7c474711a152c78b43218e296

và hình thức thân thiện với người dùng, như:

Mạng chính:

Có thể nảy:

EQC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0MhjilkPX

Không thể nảy:

UQC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0Mhjilh4S

Mạng thử nghiệm:

Có thể nảy:

kQC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0Mhjilvhd

Không thể nảy:

0QC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0MhjilqWY

Nếu quan sát kỹ các địa chỉ này, bạn có thể thấy chúng chỉ khác nhau ở ký tự đầu tiên và cuối cùng, còn `account_id` ở giữa giống nhau. Tuy nhiên, chúng ta vẫn không thể thấy được mối quan hệ giữa public key và địa chỉ tài khoản. Trên thực tế, bí ẩn nằm ở chỗ ``dữ liệu ban đầu` ở đầu chứa khóa chung của người dùng, thông qua đó người dùng kiểm soát quyền sở hữu hợp đồng ví. `workchainId` rất dễ hiểu. TON không chỉ là một chuỗi duy nhất. Nó bao gồm nhiều phân đoạn. Mỗi phân đoạn là một phần của toàn bộ mạng và xử lý một nhóm tài khoản và giao dịch cụ thể. Để định vị và quản lý các hợp đồng thông minh, cần phải chỉ rõ chúng nằm ở phân đoạn nào. Sự khác biệt giữa ``Bounceable` và `Non-bounceable` là gì? Điều này liên quan đến cơ chế hoạt động của hợp đồng thông minh, chúng ta cùng xem tiếp bên dưới nhé.

hợp đồng ví

Sau đây là mã nguồn của hợp đồng ví người dùng. Bạn có thể thấy nó đọc 4 tham số (stored_seqno, archive_subwallet, public_key, plugin) khi nhận được tin nhắn của người dùng:

ví-v4-code.fc

() recv_external(lát in_msg) không tinh khiết {

chữ ký var = in_msg~load_bits(512);

var cs = in_msg;

var (subwallet_id, valid_until, msg_seqno) = (cs~load_uint( 32), cs~load_uint( 32), cs~load_uint( 32));

Throw_if( 36, valid_until <= now());

var ds = get_data().begin_parse();

var (stored_seqno, archive_subwallet, public_key, plugin) = (ds~load_uint( 32), ds~load_uint( 32), ds~load_uint( 256), ds~load_dict());;;##Dữ liệu ban đầu

ds.end_parse();

Throw_unless( 33, msg_seqno == đã lưu trữ_seqno);

Throw_unless( 34, subwallet_id == đã lưu trữ_subwallet);

Throw_unless( 35, check_signature(slice_hash(in_msg), signature, public_key));

//...

}

Đúng vậy, khi triển khai hợp đồng ví của người dùng này, bạn cần chuyển một số tham số ban đầu, bao gồm thông tin public_key 256-bit. Điều này đảm bảo rằng mỗi người dùng có một hợp đồng độc lập khi sử dụng cùng một mã hợp đồng. Tất cả các giao dịch do người dùng thực hiện cần phải ký `in_msg`, sau đó sau khi xác minh chữ ký (check_signature) thông qua hợp đồng ví của chính họ, hợp đồng sẽ gọi tất cả các hoạt động trên chuỗi. Từ đây, chúng tôi cũng có thể suy ra rằng khóa chung của người dùng thực sự có thể tương ứng với vô số địa chỉ ví. Bạn chỉ cần triển khai các ví có mã nguồn khác nhau hoặc dữ liệu khởi tạo khác nhau để có được các địa chỉ hợp đồng hoàn toàn khác nhau.

Mã thông báo Jetton

Token là sự đại diện của tài sản trên chuỗi nên nó là yếu tố cơ bản chúng ta cần hiểu. Jetton là dạng tiêu chuẩn của mã thông báo TON Jetton bao gồm hai hợp đồng, Jetton-minter và Jetton-wallet:

Giới thiệu lần đầu về TON: Tài khoản, Token, Giao dịch và Bảo mật Tài sản

Khi mã thông báo được phát hành, hợp đồng Jetton-minter sẽ được tạo. Việc khởi tạo hợp đồng ghi lại tổng số lượng mã thông báo, quản trị viên, mã ví và các thông tin khác.

Khi mã thông báo được phân phối cho người dùng, hợp đồng Minter sẽ triển khai hợp đồng ví cho người dùng và ghi lại số dư, quyền sở hữu, địa chỉ hợp đồng mã thông báo Minter, mã ví người dùng và các thông tin khác khi mỗi người dùng sẽ triển khai một hợp đồng. một cách độc lập. Lưu ý rằng hợp đồng được tạo ở đây là hợp đồng ví được sử dụng để quản lý mã thông báo Jetton cụ thể, khác với hợp đồng ví tài khoản của người dùng ở đây ghi lại địa chỉ ví tài khoản của người dùng.

Khi người dùng Alice chuyển tiền cho người dùng Bob, mối quan hệ gọi điện như sau:

Giới thiệu lần đầu về TON: Tài khoản, Token, Giao dịch và Bảo mật Tài sản

Alice ký APP ngoài chuỗi và đưa ra hướng dẫn vận hành bằng cách gọi hợp đồng ví của cô ấy. Những hướng dẫn này còn gọi đến ví token của cô ấy để thực hiện chuyển khoản. Khi ví token của Bob nhận được token, nó sẽ thông báo hợp đồng ví của Bob (tức là địa chỉ Chủ sở hữu của ví Bob Jetton). Nếu còn Gas trong quá trình giao dịch, nó sẽ được trả về địa chỉ phản hồi, thường là hợp đồng tài khoản của Alice.

Đây là quá trình chuyển mã thông báo Jetton được phân tích cú pháp bởi trình duyệt Tonviewer:

Giới thiệu lần đầu về TON: Tài khoản, Token, Giao dịch và Bảo mật Tài sản

Chuyển khoản ERC 20 chỉ cần gọi ít nhất một hợp đồng, trong khi chuyển mã thông báo Jetton cần gọi ít nhất bốn hợp đồng. Điều này được thực hiện để cho phép chuyển khoản được thực hiện đồng thời trên chuỗi và cải thiện hiệu quả giao dịch.

buôn bán

Khi có điều gì đó xảy ra với tài khoản bằng TON, nó sẽ kích hoạt giao dịch. Sự kiện phổ biến nhất là nhận được tin nhắn.

  • Tin nhắn đến ban đầu kích hoạt hợp đồng (có một phương thức kích hoạt đặc biệt)

  • Các hành động hợp đồng do tin nhắn đến gây ra, chẳng hạn như cập nhật bộ nhớ của hợp đồng (tùy chọn)

  • Tin nhắn gửi đi cho những người tham gia khác (tùy chọn)

Giới thiệu lần đầu về TON: Tài khoản, Token, Giao dịch và Bảo mật Tài sản

Có một số đặc điểm mà bạn cần chú ý khi giao dịch:

1. Không đồng bộ: Các giao dịch TON không được hoàn thành trong một cuộc gọi. Nó có thể cần chuyển tin nhắn đến nhiều hợp đồng thông minh khác nhau để thực hiện một loạt cuộc gọi. Do định tuyến khác nhau trong chuỗi phân đoạn, TON không thể đảm bảo thứ tự gửi tin nhắn giữa nhiều hợp đồng thông minh.

2. Phí xử lý: Tính chất không đồng bộ cũng nảy sinh một vấn đề, đó là khó ước tính được phí xử lý tiêu thụ. Do đó, khi bắt đầu giao dịch, ví thường gửi thêm một số token dưới dạng phí xử lý. Nếu hợp đồng được gọi có cơ chế phí xử lý tốt thì phí xử lý còn lại cuối cùng sẽ được trả lại vào ví của người dùng. Người dùng có thể nhận thấy số token trong ví đột nhiên trở nên ít hơn và sau đó lại nhiều hơn sau vài phút. Đây là lý do.

3. Bounce: Bounce là cơ chế xử lý lỗi của hợp đồng Khi hợp đồng gọi không tồn tại hoặc đưa ra lỗi, nếu giao dịch được thiết lập là bị trả lại thì một tin nhắn bị trả lại sẽ bị trả lại cho hợp đồng gọi. Ví dụ: nếu người dùng bắt đầu chuyển khoản và xảy ra lỗi trong quá trình gọi thì cần có thông báo trả lại để hợp đồng ví của người dùng có thể khôi phục số dư. Hầu hết tất cả các tin nhắn nội bộ được gửi giữa các hợp đồng thông minh đều phải có khả năng trả lại được, tức là bit trả lại của chúng phải được đặt.

Bảo mật tài sản

TON có nhiều tính năng có thể gây ra các vấn đề về bảo mật nên người dùng cũng cần lưu ý một số cạm bẫy thường gặp.

Tấn công chặn phí

Như đã đề cập ở trên, ví thường cần gửi thêm phí xử lý để ngăn chặn lỗi thực hiện giao dịch, điều này tạo điều kiện cho kẻ tấn công tìm cơ hội làm điều ác. Nếu bạn là người dùng ví TON, bạn có thể đã gặp phải tình huống này. Bạn luôn nhận được nhiều NFT hoặc mã thông báo khác nhau trong ví của mình. Bạn nghĩ rằng đó chỉ là một số airdrop mã thông báo rác, nhưng khi kiểm tra thông tin giao dịch, bạn thấy rằng không thể. bán chúng ít tiền hơn? Tuy nhiên, khi bắt đầu giao dịch, bạn nhận thấy phí xử lý được yêu cầu là cực kỳ cao (1 TẤN). Lúc này, bạn cần chú ý. Đây có thể là hành vi gian lận phí xử lý.

Giới thiệu lần đầu về TON: Tài khoản, Token, Giao dịch và Bảo mật Tài sản

Kẻ tấn công đã sử dụng hợp đồng mã thông báo được xây dựng cẩn thận để khiến phí chuyển khoản ước tính của ví trở nên cực kỳ cao, nhưng trong quá trình thực hiện thực tế, nó chỉ giữ lại phí và không gửi tin nhắn chuyển tiền.

Câu cá số đầu và số cuối

Lừa đảo số đầu và số đuôi không phải là duy nhất đối với TON. Loại tấn công lừa đảo này tồn tại trong tất cả các chuỗi công khai lớn. Kẻ tấn công sẽ tạo một tài khoản có độ mô phỏng cao có cùng số đầu và số cuối cho mọi địa chỉ người dùng trong toàn bộ mạng. Khi người dùng gửi chuyển khoản, kẻ tấn công cũng sẽ sử dụng tài khoản có độ mô phỏng cao để gửi một khoản chuyển khoản nhỏ trong tài khoản của người dùng. để lại một bản ghi trong hồ sơ thanh toán. Khi người dùng nhận muốn chuyển mã thông báo trở lại, anh ta có thể sao chép địa chỉ từ bản ghi lịch sử. Tại thời điểm này, nó có khả năng được sao chép vào địa chỉ của kẻ tấn công, khiến kẻ tấn công có thể dự đoán chính xác địa chỉ. hành vi của người dùng.

bình luận câu cá

TON có thể thêm nhận xét khi chuyển để nhận xét thông tin giao dịch. Chức năng này thường được sử dụng khi nạp tiền trên các sàn giao dịch thường yêu cầu người dùng nhận xét ID người dùng của họ khi nạp tiền. Tuy nhiên, chức năng này thường bị khai thác một cách ác ý, với những kẻ tấn công lừa đảo tài sản của người dùng bằng cách viết thông tin gian lận vào ghi chú. Như thể hiện trong hình ảnh:

Giới thiệu lần đầu về TON: Tài khoản, Token, Giao dịch và Bảo mật Tài sản

Người dùng cần đặc biệt chú ý đến Số Telegram ẩn danh NFT. Nếu người dùng sử dụng Số Telegram ẩn danh để mở tài khoản TG nhưng không mở Xác minh hai bước, một khi NFT bị lừa đảo, tin tặc có thể đăng nhập trực tiếp vào tài khoản TG mục tiêu. và thực hiện hành vi trộm cắp tài sản sau đó.

Lỗ hổng hợp đồng thông minh

Các lỗ hổng bảo mật trong hợp đồng thông minh sẽ gây thiệt hại cho số tiền của người dùng đặt trong hợp đồng thông minh. Người dùng cần chọn các dự án được kiểm toán tốt khi lựa chọn dự án. Hợp đồng thông minh của TON chủ yếu được lập trình bằng ngôn ngữ FunC, nhưng cũng sử dụng Tact nâng cao hơn hoặc Fift cấp thấp hơn, tất cả đều là những ngôn ngữ có tính nguyên bản cao. Các ngôn ngữ lập trình mới sẽ mang đến những rủi ro bảo mật mới. Đặc biệt đối với các nhà phát triển, họ phải có thói quen tốt về lập trình an toàn, nắm vững các phương pháp bảo mật tốt nhất và trải qua quá trình kiểm tra bảo mật nghiêm ngặt trước khi triển khai vào môi trường sản xuất. không thảo luận về bảo mật hợp đồng bây giờ.

Tấn công nạp tiền giả

Người dùng ví hoặc sàn giao dịch cần chú ý đến các cuộc tấn công nạp tiền giả mạo. Thường có hai loại tấn công nạp tiền giả mạo:

  • Đối với tiền giả, kẻ tấn công phát hành mã thông báo có cùng siêu dữ liệu với mã thông báo mục tiêu. Nếu chương trình nhập tự động không kiểm tra xem đây có phải là hợp đồng đúc tiền chính xác hay không thì điều đó sẽ dẫn đến mục nhập không chính xác.

  • Trả lại, quá trình chuyển TON yêu cầu mối quan hệ gọi điện giữa các hợp đồng ví của hai người dùng. Nếu hợp đồng ví của người nhận không tồn tại và giao dịch được đặt thành Có thể trả lại, tin nhắn sẽ bị trả lại và số tiền ban đầu sẽ bị trừ khỏi. phí xử lý. Trả lại cho người gửi. Bạn bè quan tâm đến thông tin chi tiết có thể xem bài viết nạp tiền giả mà chúng tôi đã tiết lộ trước đây.

Tóm tắt

Bài viết này giới thiệu một số nguyên tắc kỹ thuật cơ bản của TON từ góc độ tạo khóa công khai và riêng tư của TON, hợp đồng ví, hình thức Token, đặc điểm giao dịch, v.v., đồng thời thảo luận về các vấn đề bảo mật có thể xảy ra trong quá trình sử dụng TON. Tôi hy vọng nó có thể giúp ích. mọi người hãy học hỏi.

Liên kết tham khảo:

https://docs.ton.org/

https://github.com/ton-blockchain/wallet-contract

Bài viết gốc, tác giả:慢雾科技。Tuyển dụng: Nhân viên kinh doanh phần mềm theo dự án report@odaily.email;Vi phạm quy định của pháp luật.

Odaily nhắc nhở, mời đông đảo độc giả xây dựng quan niệm đúng đắn về tiền tệ và khái niệm đầu tư, nhìn nhận hợp lý về blockchain, nâng cao nhận thức về rủi ro; Đối với manh mối phạm tội phát hiện, có thể tích cực tố cáo phản ánh với cơ quan hữu quan.

Đọc nhiều nhất
Lựa chọn của người biên tập