Hiện mình xin chia sẻ tổng kết mấy điểm lưu ý cho các anh em muốn áp dụng blockchain vào với bài toán nghiệp vụ:

1. Câu hỏi số 1: Lựa chọn nền tảng blockchain nào?
(ý kiến cá nhân)
👉 Ethereum, tốt cho việc transaction, song ko secure, everyone có thể join. Smartcontract luôn bị assembly di chuyển địa chỉ, dễ bị ăn cắp thông tin kiểu cracking này. Hệ thống luôn cần phải có miner để hỗ trợ việc xử lý nhanh các transaction. Ko có miner là chết. Và nếu mở ra cộng đồng bạn ko thể mình bạn giảm phí, hoặc tăng phí. Phải theo giá cả thị trường.

👉 Hyperledger Fabric, bảo mật hơn, vậy là kèm theo việc chuẩn bị các máy đào sẵn, account sẵn, bạn chỉ việc tạo logic cho business bạn cần. Mọi thứ là đóng. Giao dịch tốc độ nhanh hay chậm là do máy bạn cấu hình cao hay thấp. Chỉ tổ chức của bạn mói sử dụng được mạng đó. Và… bạn muốn làm nghiệp vụ gì cũng được. Việc build có lẽ vơi máy pc core i7, ram 16gb, ssd 512, thì chỉ trong….20 giây… là ra bất cứ hệ thống nào.

🎯 Nhưng nhược của 2 hệ trên là nó không thể cùng lúc xử lý nhanh giao dịch cỡ 10k request/ 10 mili second. Nó luôn là 1 tnx/2 giây.


2. Chướng ngại ban đầu, AUTHENTICATION
(ý kiến cá nhân)
👉 Ether thì khoá chính khoá phụ lùng bùng, đa phần các team đưa cái khoá vào db decentralized server app của mình, vấn đề rất nguy hiểm khi kẻ gian ăn cắp db. Tiếp tới họ xử lý qua SMS, vậy là nhà mạng có thông tin khách hàng của mình. Sau đó rất khó khăn khi xác nhận user đó là trong mạng Ether và thuộc ứng dụng của mình. Chưa có cơ chế làm nhanh khi bạn dừng ko cấp quyền hoặc loại trừ user đó qua mạng, vẫn phải can thiệp vào console của server.

👉 Hyperledger Fabric, mới mở một anh chaincode làm sẵn khá sừng sỏ là Hyperledger Composer. Anh này được cái lĩnh hội bảo mật từ Fabric CA, lại nghĩ ra cái trò CARD, cái này hay, tức là bây giờ ng dùng mạng của Hyperledger sẽ có 3 lớp bảo vệ: 1. username password để xác nhận bạn là bạn; 2. accesstoken để xác nhận bạn có trong luồng xử lý của mạng; 3. một card vật lý (mã rsa) để xác nhận bạn được xử lý cái gì. Như vậy nhiều bạn crack được lớp 1, 2 nhưng có làm đuợc gì đâu. Cái này rất tiện khi a em tác nghiệp thêm JWT kèm với CARD là enterprise luôn.


3. Cục gạch thứ 2, tạo các peer, join các tổ chức
(ý kiến cá nhân)
👉 Ether thì làm theo kiểu truyền thống, gọi là blockchain truyền thống có nghĩa là: cứ càng nhiều node thì phải tính toán lại công thức tìm những bạn node nào phù hợp gần nơi có transaction, và trong node đó có sẵn máy miner nào có tỷ lệ đào nhanh nhất thì cho duyệt. Cái này làm chậm đi phần nào khi 1 block đào xong. Và bạn có thể nhận thấy ngay thời gian mất đi là việc tính toán các node gần và chọn các miner nào tối ưu. Bài toán đã giảm thiểu hơn với một số team mở rộng và sửa lại thuật toán đồng thuận <– có thể làm thời gian mining các block giảm đi. Song vẫn dài, dài là một giao dịch đuợc tạo xong, vào chuyển về các node (40 node), cho tới khi bạn nhận đuợc message mất cỡ …2-10 phút. Và khi các anh em tạo tổ chức khác, bài toán khác join vào mạng bạn đang có… gần như họ phải lập trình từ đầu.

👉 Hyperledger Fabric (Fab) đuợc cái nhanh hơn, vì nó không có chuyện phải tính toán các máy mining là ok hay không. Nó chỉ tập trung nhận các transaction từ các node, và qua một bên tập trung xử lý: có thể là 1 server 4core i5, 8mb ram, ssd 256 là phục vụ cho 1k request rồi, có thể tốc độ lên tới 100 reqs/2 giây giao dịch. Vẫn chậm. Xong có thể coi là dễ thở hơn Ether. Nhưng cái hay của Fab là bạn có thể tạo nhanh ứng dụng decentralize hoặc ra các api qua 1 nốt nhạc, hay nói cách khách khi bạn nhuần nhuyên JWT và CARD, bạn có thể join bất cứ app khác nào, hoặc share bất cứ api nào bạn có.


4. Thách thức thứ 3, khi gia tăng thời gian mining, đưa thông tin vào sổ cái cho…10k request, 100k request…1tr request
(ý kiến cá nhân)
👉 Ether, gia tăng time mining bị khi mấy bạn lười đào, nào là… tiền không nhiều… server chật, nào là… băng thông có bạn. Đó bạn nên hiểu khi làm với nhiều cá nhân khác cùng luồng là như vậy. Tiếp nữa, mình không kiểm soát đuợc giao dịch đó có thực sự đuợc dốc sức cho mining hay khôgn? Ether chưa quán xuyến điều này. Dẫn tới, bạn định giảm time hoặc làm tối ưu thời gian xử lý ra sao? Cho dù bạn có viết contract logic tối ưu tới đâu cũng chịu. Vì bạn đang phụ thuộc vào một số tài nguyên khác để xử lý. Bạn không điều khiển kiểm soát đuợc tài nguyên đó. Một số team đã dedicated được một số server chỉ chuyên fix cứng loạt ip và tập trung mine cho trans nhất định. Cái đó hay. Xong nếu vậy các bạn nên chuyển sang Fab thì hơn.

👉 Fab, khi server đã đủ mạnh và đủ nhiều, tôi cứ cho là bạn có khoảng 10 con Xeon 3gnz, ram 32, ssd 1T, và kết quả là Fab có thể tăng cho bạn cỡ 10k trans/ giây. Thế cũng là cao lắm rồi. Xong để đạt 10k reqs/ 60 mini second. Chúng ta xem phần 5.


5. Trải nghiệm thứ 4, cấu hình thực tế một nhóm máy chạy chuyên hứng request
(ý kiến cá nhân)
👉 Ether, bản chất của Ether khi lưu data là file text, và xử lý cấu trúc hình cây nhị phân để lấy dược số hiệu block nhanh, từ đó truy ra các giao dịch kèm block. Vậy nó sẽ bị tắc khi có quá nhiều request lao vào, quá nhiều là cỡ 100k cùng lúc lao vào. Vậy bạn sẽ xử thế nào trong tình huống này? có lẽ bạn phải chuẩn bị một bể dữ liệu hứng sẵn request, và sau đó xử lý dần?

👉 Fab, data luu qua couchdb, câu hỏi tương tự như Ether?

🎯 Giải pháp: Chúng tôi hứng request trước, mining sau. Cụ thể:
– Cho 500k user, chuẩn bị server 3 con (1core i5 3ghz 4 lõi, 8gram, 256 ssd) dùng haproxy để load balancing. Đầu cuối decentralized server app là Nodejs và CouchDB (một dạng key value mà có thể clustering được) chuyên để hứng dữ liệu request
– Sau khi request để trong bể có thể đưa ngay sang parquet để dễ cho việc dùng scala/python kèm Spark dataframe phân tích dữ liệu ngay, nóng.
– Sau khi request để trong bể, làm ngay service cứ 2 giây đưa vào chain để mine. Tôi nghĩ cái này sẽ không gây ngột bất cứ mạng blockchain nào.


6. Trải nghiệm tứ 5, cấu hình thực thế để xử lý bigdata với data đang có để làm phân tích dữ liệu
(ý kiến cá nhân)
🎯 Thật khó khi bạn không dùng dịch vụ ngoài (hortonworks, databricks, hay cassandra) để xử lý dữ liệu lớn, bạn tự cấu hình sẽ rất vất vả. Như bên mình tự cấu hình nên quản lý rất nhiều thứ. Mà maximum trải nghiệm cả việc load dữ liệu về, đưa dữ liệu lên, rồi lưu dữ liệu tối ưu… a e chỉ dùng parquet. Không gì hơn. Xử lý thì Spark rdd, dataframe, gzip. Tôi nghĩ là tốt rồi. Vì tốc độ bạn cứ tham khảo trên internet nhé. Và độ nén để giảm khối lượng dữ liệu lớn. Tôi tin nó là Max rồi.

Xong vấn đề là, sau khi ứng dữ liệu ở (5) thì cần làm gì tiếp theo để đưa sang bể dữ liệu phân tích:
+ Cần viết microservice để chuyển bất cứ bản ghi nào được update sang parquet. Gợi ý nodejs là dễ nhất. Spark có stream, vậy hãy tạo sẵn các api lấy data từ couchdb của Fab hay text file của Ether. 
+ Cần viết service Akka để hứng dữ liệu thu thập bằng tay từ nơi khác. Vì chỉ có Spark giao tiếp tốt nhất với Akka thôi, nếu bạn muốn service hoá các dịch vụ Bigdata
+ Cần viết microservice để NLP các dữ liệu dạng text. Còn dữ liệu dạng file, data binary thì đưa sang ipfs để làm sau đó với các thư viện khác.
+ Về phía client, cần đưa các model về và lưu ở localstorage (browser) để công tác so sánh, xác minh đuợc nhanh qua web-based.

Còn ý kiến của bạn? xin được chỉ giáo thêm.

————————————————–
🎯Vậy để biết lập trình ứng dụng Blockchain cho các bài toán business, mời anh chị em vào Khóa học DevBC19 – Blockchain 4 business online, 550k, tại (testerpro.org/edu).
https://www.testerpro.org/edu/course/index.php?categoryid=4

Anh chị em đăng ký gmail, login, activate mail, rồi học thử. Học thử thích rồi hãng đăng ký chính thức. Thanks!

Welcome!
BR,
KJ (testerpro.org/admincv)

Comments

comments