Whitepaper Request Network T÷ìng lai cıa th÷ìng m⁄i M⁄ng l ...Whitepaper Request Network...

23
Whitepaper Request Network Tương lai cıa thương m/i M/ng lưi yêu cƒu thanh toán phi t“p trung Ngày 15 tháng 3 năm 2018 Mc lc 1 Tóm lưæc 2 2 N•n t£ng 2 3 H» sinh thái 7 3.1 Lp Nhân (Core) ........................................... 7 3.2 Lp Ti»n Ích M Rºng ........................................ 7 3.3 Lp ng Dng ............................................ 8 4 Hoàn c£nh sß dng 9 4.1 L“p hoá đơn B2B ........................................... 9 4.2 Thanh toán trüc tuy‚n ........................................ 10 4.3 Tü đºng hóa: K‚ toán, Ki”m toán, Chi phí ............................ 11 4.3.1 K‚ toán ............................................ 11 4.3.2 Ki”m toán ........................................... 12 4.3.3 Chi phí ............................................ 14 4.4 Quy t›c Kinh doanh và Lu“t Thương m/i: Chính phı và Thu‚ ................. 15 4.5 Đơn gi£n hóa các công c thương m/i: Chuy”n nhưæng næ (factoring), Ký qu (escrow) ... 15 4.6 Tính minh b/ch cıa các tŒ chøc .................................. 15 4.7 IoT và hæp đng thông minh .................................... 16 5 Token 16 5.1 Khuy‚n khích mºt h» sinh thái các øng dng an toàn ....................... 16 5.2 Qu£n tr ................................................ 16 5.3 Đºc l“p vi các lo/i ti•n t» khác .................................. 17 5.4 Đºc l“p v• k thu“t ......................................... 17 5.5 Đơn gi£n hóa trao đŒi liên ti•n t» .................................. 17 6 B£n th£o lº trình 17 7 Đºi ngũ 18 7.1 Nhóm chính .............................................. 18 8 Ki‚n trúc 20 8.1 Các cân nh›c k thu“t ........................................ 21 8.2 Ki‚n trúc hæp đng thông minh ................................... 22 1

Transcript of Whitepaper Request Network T÷ìng lai cıa th÷ìng m⁄i M⁄ng l ...Whitepaper Request Network...

Page 1: Whitepaper Request Network T÷ìng lai cıa th÷ìng m⁄i M⁄ng l ...Whitepaper Request Network T÷ìng lai cıa th÷ìng m⁄i M⁄ng l÷îi y¶u cƒu thanh to¡n phi t“p trung

Whitepaper

Request Network

Tương lai của thương mại

Mạng lưới yêu cầu thanh toán phi tập trung

Ngày 15 tháng 3 năm 2018

Mục lục

1 Tóm lược 2

2 Nền tảng 2

3 Hệ sinh thái 73.1 Lớp Nhân (Core) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.2 Lớp Tiện Ích Mở Rộng . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.3 Lớp Ứng Dụng . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

4 Hoàn cảnh sử dụng 94.1 Lập hoá đơn B2B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94.2 Thanh toán trực tuyến . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104.3 Tự động hóa: Kế toán, Kiểm toán, Chi phí . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4.3.1 Kế toán . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.3.2 Kiểm toán . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.3.3 Chi phí . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.4 Quy tắc Kinh doanh và Luật Thương mại: Chính phủ và Thuế . . . . . . . . . . . . . . . . . 154.5 Đơn giản hóa các công cụ thương mại: Chuyển nhượng nợ (factoring), Ký quỹ (escrow) . . . 154.6 Tính minh bạch của các tổ chức . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.7 IoT và hợp đồng thông minh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5 Token 165.1 Khuyến khích một hệ sinh thái các ứng dụng an toàn . . . . . . . . . . . . . . . . . . . . . . . 165.2 Quản trị . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165.3 Độc lập với các loại tiền tệ khác . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175.4 Độc lập về kỹ thuật . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175.5 Đơn giản hóa trao đổi liên tiền tệ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

6 Bản thảo lộ trình 17

7 Đội ngũ 187.1 Nhóm chính . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

8 Kiến trúc 208.1 Các cân nhắc kỹ thuật . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218.2 Kiến trúc hợp đồng thông minh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

1

Page 2: Whitepaper Request Network T÷ìng lai cıa th÷ìng m⁄i M⁄ng l ...Whitepaper Request Network T÷ìng lai cıa th÷ìng m⁄i M⁄ng l÷îi y¶u cƒu thanh to¡n phi t“p trung

9 Cảm ơn 23

10 Trích dẫn 24

1 Tóm lược

Request là một nền tảng phi tập trung1 cho phép mọi người yêu cầu thanh toán (một hóa đơn Request) màqua đó người nhận yêu cầu có thể tiến hành thanh toán một cách an toàn. Tất cả các thông tin được lưu trữtrong một sổ cái xác thực phân cấp (decentralized authentic ledger). Kết quả là thanh toán trở nên rẻ, tiệnlợi và an toàn hơn kèm theo một loạt các khả năng tự động hóa.

Với mục tiêu trở thành trụ cột của thương mại toàn cầu, Request tích hợp một sổ cái chung (theo nghĩathuật ngữ kế toán) mang tính:- Phổ cập vì nó được thiết kế để hỗ trợ 100% các giao dịch toàn cầu, bất kể loại tiền tệ, luật pháp hay ngônngữ. Request được phát triển cho tương lai.- Thông minh vì không giống như một sổ sách kế toán thông thường, Request quay về nguồn gốc của việctrao đổi và tích hợp một ngôn ngữ thương mại của máy tính, cũng như hệ thống quản lý vô số các điều khoảnthanh toán.

Ngày nay, việc thiếu những yếu tố trên khiến cả hệ thống trở nên kém hiệu quả và hoàn toàn chưa sẵnsàng cho cuộc cách mạng số và IoT (Internet Of Things) vốn đang diễn ra.

Request có thể được xem là một lớp dựa trên Ethereum2, cho phép các yêu cầu thanh toán nào thỏa mãnmột khuôn khổ pháp lý. Các đơn vị tiền tệ cũng có thể xem là công cụ để hoàn thành giao dịch Request.Trong trường hợp này, Request mang tính toàn cầu hơn bất kỳ loại tiền tệ nào.

2 Nền tảng

Bất cứ ai cũng có thể ghi lên sổ cái Request và tạo một yêu cầu (Request) thanh toán. Request có thể đượcnhận biết bởi người nhận khi theo dõi hệ thống mạng (thông qua ví hoặc ứng dụng tài chính). Nếu yêu cầuđược duyệt bởi người dùng, việc thanh toán chỉ cần một cú nhấp chuột. Sau đó yêu cầu được hoàn thành vàcập nhật lên mạng lưới.

Khi một Request được tạo, luật thương mại ứng với từng trường hợp cụ thể đều được tính đến và thuếsuất được áp dụng. Khi cần thiết, các điều khoản thanh toán nâng cao cũng có thể được chọn.

1http://gavwood.com/paper.pdf, 2014, Gavin Wood. Ethereum: a secure decentralised generalised transaction ledger2https://github.com/ethereum/wiki/wiki/White-Paper

2

Page 3: Whitepaper Request Network T÷ìng lai cıa th÷ìng m⁄i M⁄ng l ...Whitepaper Request Network T÷ìng lai cıa th÷ìng m⁄i M⁄ng l÷îi y¶u cƒu thanh to¡n phi t“p trung

Bob đang gửi yêu cầu thanh toán cho Alice

Hãy xem thử 2 ví dụ sau:Bob yêu cầu Alice thanh toán, sau đó anh ta tạo một yêu cầu (hóa đơn) và chuyển nó lên blockchain. Ví củaAlice phát hiện yêu cầu Request và tiến hành thanh toán.Trong trường hợp Bob trên Amazon và Alice đang mua hàng, Amazon sẽ tạo một Request trên blockchain,điện thoại của Alice phân tích blockchain và phát hiện Request đó, liền gửi một thông báo và cô ấy đồng ýtrả tiền.

Request mang đến:

• An toàn, vì không cần phải chia sẻ thông tin ngân hàng

• Sự đơn giản, vì chỉ cần 1 cú nhấp chuột

• Tiết kiệm, vì việc mua hàng không cần bên thứ ba (ví dụ: Paypal)

3

Page 4: Whitepaper Request Network T÷ìng lai cıa th÷ìng m⁄i M⁄ng l ...Whitepaper Request Network T÷ìng lai cıa th÷ìng m⁄i M⁄ng l÷îi y¶u cƒu thanh to¡n phi t“p trung

Minh họa của sổ cái chung (General Ledger)

Xem xét một ví dụ thứ hai, trong đó một chiếc xe tự lái kết nối với một hợp đồng thông minh của garageđể mua một bánh xe mới. Cả hai tự thương lượng theo thuật toán và đồng ý thanh toán với tiền đặt cọc vàký quỹ (tiền chỉ được trả khi giao hàng). Để tương tác về mặt tài chính, máy móc và IoT đòi hỏi một khuônkhổ thanh toán.

Những ví dụ trên hiện không khả thi vì thiếu một định dạng tiêu chuẩn và thiếu sự liên kết giữa các dịchvụ. Muốn vậy việc chia sẻ thông tin ngân hàng hoặc sử dụng một bên thứ ba được biết đến bởi cả hai bên(Paypal, Venmo, Lydia, Stripe ...) là cần thiết. Bên cạnh những hạn chế về nhiều mặt và không an toàn,nhiều hoá đơn đơn lẻ rất hay bị sai sót.

Blockchain là sự hỗ trợ hoàn hảo để tạo ra một hệ thống mã nguồn mở, bền vững, thông minh và khôngthể bị tác động (immutable).

4

Page 5: Whitepaper Request Network T÷ìng lai cıa th÷ìng m⁄i M⁄ng l ...Whitepaper Request Network T÷ìng lai cıa th÷ìng m⁄i M⁄ng l÷îi y¶u cƒu thanh to¡n phi t“p trung

Những nền tảng mới này đơn giản hóa những luồng giao dịch điện tử. Điều này là vô cùng quan trọngbởi vì mọi thứ đều quy về việc thanh toán. Hơn năm ngàn tỉ đô la được giao dịch mỗi ngày3 tính riêng trênmạng SWIFT. Tuy nhiên, những luồng giao dịch này lại kém tối ưu.

Giải pháp này của Request mang đến những ưu điểm tốt hơn hẳn. Một sổ cái chứa tất cả các mục nhậpkế toán chuẩn có thể tự động hoá theo thời gian thực, cải tiến kiểm toán, tự động hóa chuyển nhượng nợ,đơn giản hoá báo cáo chi tiêu, làm cho việc ký quỹ trở nên đơn giản và đáng tin cậy, cũng như phát hiện vàtự động thanh toán thuế.

3https://www.fincen.gov/sites/default/files/shared/Appendix_D.pdf

5

Page 6: Whitepaper Request Network T÷ìng lai cıa th÷ìng m⁄i M⁄ng l ...Whitepaper Request Network T÷ìng lai cıa th÷ìng m⁄i M⁄ng l÷îi y¶u cƒu thanh to¡n phi t“p trung

Hơn nữa, nó mở ra những cơ hội cho những cải cách thương mại toàn diện hơn.

Việc có thể quản lý dữ liệu riêng tư khiến cho việc đẩy mạnh thương mại trở nên minh bạch hơn (côngkhai chi tiêu, kết hợp), công bằng hơn (sự minh bạch khiến ta có thể theo dõi sự phân phối của thặng dư vànguồn gốc của sản phẩm; nó cũng tăng cường công bằng thương mại) và mang tính công lý hơn (các quy tắcthương mại sẽ dễ dàng được liên kết và thực thi).

Thật khó để tưởng tượng rằng thế giới tài chính có thể cải tiến nếu không có hệ thống này.

6

Page 7: Whitepaper Request Network T÷ìng lai cıa th÷ìng m⁄i M⁄ng l ...Whitepaper Request Network T÷ìng lai cıa th÷ìng m⁄i M⁄ng l÷îi y¶u cƒu thanh to¡n phi t“p trung

3 Hệ sinh thái

3.1 Lớp Nhân (Core)

Lớp dưới cùng là lớp Nhân (Core), quản lý sự thỏa thuận trên sổ cái và các trạng thái chuyển tiếp. Nó baogồm các hợp đồng thông minh (smart contracts) cơ bản nhất, cho phép tạo ra các thực thể và yêu cầu thanhtoán khác nhau. Nó cũng phát hiện khi các khoản thanh toán đã được hoàn thành. Nó dựa trên tính bấtbiến (nghĩa là không ai có thể thay đổi thông tin), sự minh bạch của hệ thống (mọi người đều có thểtruy cập thông tin liên quan đến họ) và tính thông minh cho phép nó biết khi nào hóa đơn được thanhtoán theo các quy tắc trong hóa đơn.

Lớp này được đặt trên blockchain của Ethereum, đem lại những lợi ích nội sinh cho Ethereum và các hóađơn ERC-20, chẳng hạn như tự động phát hiện. Việc sử dụng Oracles cũng giúp đảm bảo việc chi trả cácloại tiền tệ khác thông qua sự phát hiện chi trả tự động.

Lớp này hoàn toàn miễn phí để khuyến khích việc sử dụng nhiều nhất và hạn chế việc phát triển nhữnghệ thống khác. Chi phí duy nhất được truyền tải là việc sử dụng khí Ethereum và lưu trữ thông tin.

3.2 Lớp Tiện Ích Mở Rộng

Lớp thứ hai là lớp Tiện Ích Mở Rộng. Hầu hết các yêu cầu thanh toán ngày nay không đơn giản như đềcập trong lớp Chính (Core). Nếu một yêu cầu thanh toán đến từ doanh nghiệp thì nó thường sẽ có cả cácquy tắc để tính toán thuế, điều khoản thanh toán, các khoản ký quỹ hoặc tạm ứng. Tất cả các điều kiệnnày đều thuộc dạng tiện ích mở rộng có thể được thêm vào yêu cầu thanh toán. Lớp này là mở đầu cho cáctính năng tuyệt vời chưa hề tồn tại, chẳng hạn như "các hóa đơn liên tục". Ví dụ, một người có thể chọnmô-đun này để chia nhỏ tiền thuê của họ thành những khoản chi trả 30x24 cho chủ nhà, giúp người này có

7

Page 8: Whitepaper Request Network T÷ìng lai cıa th÷ìng m⁄i M⁄ng l ...Whitepaper Request Network T÷ìng lai cıa th÷ìng m⁄i M⁄ng l÷îi y¶u cƒu thanh to¡n phi t“p trung

được thanh khoản dồi dào mà không phải chi những khoản tiền lớn vào cuối tháng. Thuế sẽ được chuyểntheo thời gian thực cho các cơ quan chính phủ. Với mỗi lần thanh toán, 20% sẽ là thuế VAT và công ty nhận80% còn lại. Một ví dụ tương tự sẽ cho phép mọi người quyên góp 1% trên tất cả các khoản thanh toán chocác tổ chức phi chính phủ (NGO) hoặc gửi tiền vào tài khoản hưu trí của chính họ.

Lớp này sẽ bị tính phí, đối với những tiện ích tích lũy trong cùng một hóa đơn, mỗi tiện ích sẽ thu mộtkhoản phí mà trong đó một phần để khấu hao và một phần được chuyển cho các nhà phát triển tiện ích. Chiphí này sẽ giảm dần theo thời gian để tăng tính cạnh tranh và hạn chế việc phát triển những hệ thống thaythế. Chi phí của các phần mở rộng này được ước tính ban đầu từ 0.05% đến 0.5%, tuy nhiên khi hệ thốngphát triển, chi phí sẽ giảm. Với hơn 5000 tỷ đô la được thanh toán mỗi ngày, dần dần chi phí hoạt động chomạng lưới sẽ ít hơn 0.1%. Dù gì đi nữa, chi phí này sẽ tiếp tục được dùng để hỗ trợ bảo mật và phát triểncác ứng dụng.Lớp này hoàn toàn mở. Bất cứ ai cũng có thể tạo ra các tiện ích của riêng mình với phí sử dụng sẽ đượcphân chia một cách cạnh tranh để thu hút và khuyến khích nhà phát triển cũng như cộng đồng.

3.3 Lớp Ứng Dụng

Lớp trên cùng là lớp Ứng Dụng nằm ngoài blockchain. Các hệ thống của các công ty khác nhau có thể kếtnối với Request để tạo yêu cầu hoặc truy cập thông tin. Kế toán, kiểm toán, thuế, thu hồi nợ, chuyển nhượngnợ và hệ thống thanh toán đều có thể được liên kết. Khi một hệ thống thanh toán kết nối với Request(Mycellium, Coinbase, Bank of America, Bankin v.v), nó sẽ có thể truy cập hoá đơn của người sử dụng vàđề nghị thanh toán ngay lập tức.

Nhóm Request sẽ phát triển các ứng dụng, bao gồm một giao diện và một API để tạo và truy cập cácyêu cầu thanh toán.

8

Page 9: Whitepaper Request Network T÷ìng lai cıa th÷ìng m⁄i M⁄ng l ...Whitepaper Request Network T÷ìng lai cıa th÷ìng m⁄i M⁄ng l÷îi y¶u cƒu thanh to¡n phi t“p trung

Ứng dụng Tín nhiệmMột hệ thống đánh giá độ tín nhiệm được bao gồm trong lớp này để bảo vệ chống lừa đảo hoặc người trảtiền mờ ám. Ví dụ, người sử dụng có thể phát hiện nếu một công ty đang thực hiện hành vi lừa đảo khi thấynhững người dùng khác trước đây đã từ chối thanh toán cho công ty này. Ngược lại, nếu một công ty khôngthanh toán hóa đơn theo đúng thời gian, sau khi đã chấp nhận hóa đơn đó, cũng sẽ bị phạt trừ điểm tínnhiệm. Ứng dụng Tín nhiệm còn nhiều công dụng khác; ví dụ, các thành viên của mạng với điểm tín nhiệmcao sẽ được giảm chi phí hoặc được truy cập các ứng dụng riêng.

Mức độ tín nhiệm có thể được trực tiếp cập nhật vào blockchain, nhưng để giữ cho hệ thống linh hoạt,chúng tôi quyết định đặt nó vào lớp Ứng dụng bởi vì thông tin này có thể lấy lại được khi rà soát blockchain.

4 Hoàn cảnh sử dụng

Các hoàn cảnh sử dụng cho công nghệ này vô cùng rộng. Hệ thống này tự động hóa kế toán toàn cầu theothời gian thực, thay thế toàn bộ quy trình kiểm toán, loại bỏ việc thu thuế thủ công, đơn giản hóa thanhtoán quốc tế, cho phép các máy tính giao tiếp trên cùng một lĩnh vực tài chính, thay thế các hệ thốngthanh toán như Paypal, và đưa ra các điều khoản thanh toán tiên tiến nhất có sẵn cho tất cả mọi người.

4.1 Lập hoá đơn B2B

Hàng tỷ hoá đơn được chia sẻ mỗi năm giữa các công ty mà hầu hết vẫn được gửi bằng giấy hoặc email vốncần phải được sao lưu. Điều này gây ra rất nhiều lỗi, đặc biệt khi liên quan đến các điều khoản thanh toánhoặc các quy tắc về thuế phức tạp.

Với Request, các công ty có thể chia sẻ các hóa đơn trực tiếp qua sổ cái; sẽ không còn bị trùng lắp, vì cáchệ thống kế toán sẽ được kế nối và cập nhật ngay tức thời.

Một công ty đang chờ thanh toán sẽ có thể phát hiện ra sự chậm trễ ngay lập tức, một điều mà sẽ ít xảyra hơn nhờ vào sự phát triển của các hệ thống thanh toán hoá đơn. Công ty này sẽ có khả năng thanh toánvào một ngày tối ưu tại thời điểm nhận được yêu cầu.

Hàng năm, hàng ngàn doanh nghiệp vừa và nhỏ (SMEs) bị phá sản trong khi chờ đợi các hoá đơn đượcthanh toán. Cụ thể là ECB (Ngân hàng Trung ương Châu Âu) đang thiết lập các giải pháp mà theo đóRequest sẽ hoàn thiện bằng cách thêm một hệ thống đánh giá tín nhiệm thanh toán và các chỉ số chính.Ngày nay, một nhà cung cấp vẫn phải tin tưởng khách hàng của họ và chấp nhận rủi ro có thể không đượcthanh toán. Trong tương lai, nhà cung cấp sẽ có thể xác minh uy tín của khách hàng và các chỉ số khác,chẳng hạn như DPO (Days Payable Outstanding) trước khi đồng ý thực hiện một hợp đồng.

9

Page 10: Whitepaper Request Network T÷ìng lai cıa th÷ìng m⁄i M⁄ng l ...Whitepaper Request Network T÷ìng lai cıa th÷ìng m⁄i M⁄ng l÷îi y¶u cƒu thanh to¡n phi t“p trung

4.2 Thanh toán trực tuyến

Ví dụ, việc mua sắm trên Amazon yêu cầu phải thanh toán bằng thẻ tín dụng/thẻ ghi nợ, dẫn đến nguy cơtiết lộ thông tin nhạy cảm. Tuy nhiên, nếu bạn chọn thanh toán bằng Request, dữ liệu người dùng của bạnhoàn toàn được bảo vệ. Amazon sẽ gửi một Request lên mạng lưới, tài khoản của người dùng sẽ tự động pháthiện ra nó và yêu cầu xác nhận thanh toán từ người dùng. Một giao dịch chuyển khoản sẽ được thực hiệnvới chi phí thấp nhất mà không phải tiết lộ thông tin thanh toán.

Người dùng có thể tránh được các khoản thanh toán thẻ tín dụng/thẻ ghi nợ không mong muốn mà cácdịch vụ tính phí không rõ ràng, bởi vì Request cung cấp khả năng xác thực thanh toán trước khi chúng xảy ra.

Những ưu điểm của Request, so với các hệ thống hiện tại, là:

• Bảo mật: Thông tin thanh toán không bao giờ được chia sẻ nên không có nguy cơ bị đánh cắp và sửdụng.

• Đơn giản: Một cú nhấp chuột để trả tiền và loại bỏ lỗi nhập liệu thủ công.

10

Page 11: Whitepaper Request Network T÷ìng lai cıa th÷ìng m⁄i M⁄ng l ...Whitepaper Request Network T÷ìng lai cıa th÷ìng m⁄i M⁄ng l÷îi y¶u cƒu thanh to¡n phi t“p trung

• Chi phí rẻ: Không có các bên thứ ba như Paypal4, Bitpay5 hoặc Stripe6, tính phí bạn từ 1% đến 7%trên số tiền gửi. Request giúp giảm chi phí này.

4.3 Tự động hóa: Kế toán, Kiểm toán, Chi phí

4.3.1 Kế toán

Với Request, quy trình kế toán được thực hiện tự động và theo thời gian thực. Ngoài việc tiết kiệm chi phí,điều này cho phép quản lý tài chính tốt hơn, nhanh hơn và với nhiều thông tin hơn.

Hoàn cảnh sử dụng cho các mục đích kế toán:Request đem đến sự đồng thời vào quá trình kế toán. Thanh toán, hạch toán, và hoàn thuế VAT đềuđược thực hiện tự động.

4https://www.paypal.com/en/webapps/mpp/paypal-fees5https://bitpay.com/pricing6https://stripe.com/nl/pricing

11

Page 12: Whitepaper Request Network T÷ìng lai cıa th÷ìng m⁄i M⁄ng l ...Whitepaper Request Network T÷ìng lai cıa th÷ìng m⁄i M⁄ng l÷îi y¶u cƒu thanh to¡n phi t“p trung

Hơn nữa, Request còn đại diện cho một sự chuyển đổi từ nguyên tắc ghi sổ kép7 sang ghi sổ ba lần8. Đâylà một cuộc cách mạng, đúng theo dự đoán của các chuyên gia, khiến mọi người hoài nghi về giá trị tương laicủa kiểm toán bên ngoài (external audit). Thật vậy, một điểm xác nhận thứ ba được thêm vào hệ thống ghisổ kép9, và đây là điểm mà các công ty kiểm toán hiện đang đóng vai trò xác nhận tính xác thực của tài khoản.

Ngoài ra, Request cho phép số hoá các hệ thống kế toán, vốn dĩ đang ngốn thời gian để nhân đôi nỗlực thông qua việc ghi chép tài liệu và kiểm tra thường xuyên. Những nhiệm vụ thủ công này giờ đây hoàntoàn có thể được tự động hóa. Request sẽ chuyển vai trò của một CPA sang các hoạt động tư vấn và hỗ trợ.Hệ thống này đem lại nhiều thời gian hơn cho các công việc đem lại giá trị cao, chẳng hạn như phân tích,dự tính và lên chiến lược.

Về mặt kỹ thuật, ghi chú tín dụng, đơn đặt hàng, hoàn phí và mọi khái niệm kế toán đều có thực hiệntrên nền Request. Hệ thống này sẽ tương thích với tiêu chuẩn của UN / EDIFACT và có thể được cập nhậttheo những tiêu chuẩn mới nhất.

4.3.2 Kiểm toán

Với Request, kiểm toán trở thành một bài kiểm tra thuật toán đơn giản, nhờ sự bất biến của hệ thống. Để sosánh, vào năm 2014, Microsoft trả 46,2 triệu USD phí kiểm toán cho Deloitte10. Tương tự, Bank of Americađã trả gần 100 triệu USD. 100 công ty lớn nhất ở Hoa Kỳ đã chi trả tổng cộng 2,5 tỷ USD cho chi phí kiểm toán.

Từ nay, kiểm toán sẽ được tiến hành theo thời gian thực11. Đây được gọi là Kiểm toán Thông minh12

(Smart Audits). Giải pháp kiểm toán bằng blockchain (“kiểm toán thông minh”) có thể trở thành một giảipháp thay thế đáng tin cậy và tiết kiệm cho kiểm toán thủ công như hiện nay.

Request mang lại những lợi ích đáng kể cho việc nâng cao hiệu quả của các lần kiểm toán. Về mặt số hóa,phần mềm kế toán, chính phủ tiểu bang và các công ty chưa được tối ưu hóa. Nhiều công ty gửi hóa đơn quathư tín mỗi ngày, và hầu hết trong số họ đều thiếu mất hoá đơn vào cuối mỗi năm.

7https://en.wikipedia.org/wiki/Double-entry_bookkeeping_system8http://iang.org/papers/triple_entry.htmlhttps://en.wikipedia.org/wiki/Momentum_accounting_and_triple-entry_

bookkeeping9https://bitcoinmagazine.com/articles/triple-entry-bookkeeping-bitcoin-1392069656/

10http://fortune.com/2015/08/27/microsoft-pays-more-than-apple-for-its-audit-and-why-investors-should-care/11http://economia.icaew.com/features/july-2016/how-blockchain-will-impact-accountants-and-auditors12https://request.network/assets/pdf/request_yellowpaper_smart_audits.pdf

12

Page 13: Whitepaper Request Network T÷ìng lai cıa th÷ìng m⁄i M⁄ng l ...Whitepaper Request Network T÷ìng lai cıa th÷ìng m⁄i M⁄ng l÷îi y¶u cƒu thanh to¡n phi t“p trung

Tuy nhiên, các quy tắc là rõ ràng. Các phương pháp và công nghệ hỗ trợ có thể thay đổi mọi thứ và thay thếsự kiểm soát tốn kém giữa các công ty và chi nhánh, được thực hiện để đảm bảo độ tin cậy của báo cáo kế toán.

Trong ngành tư vấn điện toán, chi phí theo thời gian của nhân viên kế toán để xử lý một hoá đơn làkhoảng từ 5Øn1513. Thời gian cần thiết để kiểm tra và sửa sai hàng tháng có thể bị thêm vào chi phí này.Tự động hóa toàn bộ hệ thống hiện vẫn khá chậm.

Việc sử dụng blockchain cho kế toán là một cơ hội để đơn giản hóa việc tuân thủ và cải thiện việc ghi sổkép. Nguyên tắc ghi sổ kép có từ thời Phục Hưng, giúp các nhà quản lý có niềm tin vào các báo cáo của họ.Ngày nay, để chứng minh sự tin tưởng, kiểm toán viên độc lập cần xác minh thông tin của các tập đoàn lớntheo một quy trình tốn kém cả về thời gian và tiền bạc. Công ty kiểm toán sau đó trở thành một bên thứ batin cậy nhằm đảm bảo tính xác thực của thông tin bằng báo cáo tài chính. Tuy nhiên, kiểm toán viên vẫnduy trì trách nhiệm đối với các công ty, tạo ra sự không đáng tin. Liệu kiểm toán viên làm việc cho ngườiquản lý của các công ty ủy thác họ, hay làm dịch vụ tư vấn thông tin miễn phí của các bên thứ ba?

Chính vì vậy, thay vì lưu trữ các tài khoản nội bộ và công bố sau khi kiểm toán hàng năm, các công ty cóthể giữ tài khoản trong một cơ sở dữ liệu phi tập trung được bảo mật và chia sẻ và với công nghệ blockchain.Tất cả mục kế toán sau đó được nhập vào sổ đăng ký, không có khả năng sửa thông tin trong quá khứ, nghĩalà không có cơ hội giả mạo. Vì vậy, những điều chỉnh đáng ngờ vào cuối năm sẽ khó thực hiện hơn, và quantrọng nhất, công ty hưởng lợi từ hệ thống này theo thời gian thực. Cổ đông và đối tác bên ngoài cũng cóquyền truy cập thông tin theo thời gian thực. Chi phí kiểm toán trở nên không đáng kể, và việc nhập liệukhông còn cần kiểm tra thủ công thêm. Cuối cùng, tính toàn vẹn của báo cáo tài chính được đảm bảo khikhách hàng và nhà cung cấp được kết nối với hệ thống này, ít nhất bằng địa chỉ mã hóa của họ.

Request là một sổ đăng ký phi tập trung đóng vai trò như một nguồn tin cậy, cho phép thực hiện “kiểmtoán thông minh” trong thời gian thực. Nó bao gồm tất cả các giao dịch mua bán của công ty. Thay vì phảighi sổ kép, khi mà thông tin mua hàng xuất hiện trong tài khoản mua hàng và trong tài khoản ngân hàngkhác nhau, người ta có thể thấy bên trong blockchain rằng một tài khoản mua gắn với nhà cung cấp đượcliên kết với thanh toán và tài khoản ngân hàng. Có thể theo dõi, bất biến và xác thực.

13http://ww2.cfo.com/expense-management/2015/06/metric-month-accounts-payable-process-cost/, 06/24/2015, MaryDriscoll

13

Page 14: Whitepaper Request Network T÷ìng lai cıa th÷ìng m⁄i M⁄ng l ...Whitepaper Request Network T÷ìng lai cıa th÷ìng m⁄i M⁄ng l÷îi y¶u cƒu thanh to¡n phi t“p trung

Request chứng minh tính toàn vẹn của các hồ sơ lưu trữ điện tử. Đây là một cửa ngỏ cho thương mạitrong tương lai.

4.3.3 Chi phí

Với Request, báo cáo chi phí có thể dễ dàng được chia sẻ giữa nhân viên và doanh nghiệp mà không bị thấtlạc hoặc thay đổi. Một hệ thống quản lý chi phí sẽ cho phép nhân viên lựa chọn và gửi theo thời gian thựcchi phí công việc cho người quản lý của họ để phê duyệt và hoàn lại tiền khi đã sẵn sàng.

4.4 Quy tắc Kinh doanh và Luật Thương mại: Chính phủ và Thuế

Các chính phủ đòi hỏi các công ty phải báo cáo về tất cả các giao dịch, việc này có thể tạo ra những sai sótvà trùng lặp. Request cho phép các chính phủ xem cụ thể các giao dịch mà họ có quyền truy cập theo thờigian thực.Không chỉ vậy, việc phát triển một mô-đun để trưng thu thuế VAT, hoặc ví dụ một khoản thuế xuyên đạidương, sẽ chuyển hướng dòng tiền một cách tự động.Cho dù là thuộc về chính phủ hay không, lần đầu tiên ta có thể thấy sự cải tiến rõ rệt để đơn giản hóa vàminh bạch các khoản trưng thu thuế.

Công nghệ blockchain cho phép các cơ quan chính phủ có khả năng phát hiện sự bất ổn định về tài chính,lừa đảo, rửa tiền và tội phạm tài chính sớm và tiến hành xử lý dựa trên những quan sát này.

Giới khoa học của chính phủ Anh gần đây đã xác định được một số cách mà blockchain có thể "Cáchmạng hóa quan hệ công dân - nhà nước". Ví dụ: giúp chính phủ thu thuế và phân phối viện trợ.

4.5 Đơn giản hóa các công cụ thương mại: Chuyển nhượng nợ (factoring), Kýquỹ (escrow)

Request sẽ cho phép các doanh nghiệp và cá nhân dễ dàng truy cập vào các công cụ như ký quỹ hoặc chuyểnnhượng nợ. Chỉ cần 1 cú nhấp chuột để chọn chỉ thanh toán khi giao hàng hoặc để đảm bảo một khoản đặtcọc cho căn hộ dựa trên việc ký quỹ thay vì tín dụng vào tài khoản của chủ nhà.

Tất cả diễn ra một cách đơn giản với chi phí thấp hơn nhiều. Thật vậy, ký quỹ có thể được tự động vàdựa trên oracles. Đối với việc chuyển nhượng nợ, các công ty sẽ có thể sử dụng hệ thống điểm tíndụng uy tín nhất hiện nay: “On Chain” . Bằng cách chỉ định một danh tính duy nhất cho mỗi hóa đơnvà phát hành lên blockchain, việc lập hoá đơn trùng lắp sẽ không còn vì một hóa đơn chỉ có thể được mãhoá một lần duy nhất trên blockchain. Một hợp đồng thông minh sau đó sẽ cho phép các công ty đó hủy bỏmột yêu cầu hiện tại để thay thế nó bằng 2 yêu cầu chuyển nhượng nợ.

4.6 Tính minh bạch của các tổ chức

Sự minh bạch ngân sách của các thể chế (chính phủ, hội đồng thành phố, hiệp hội) nằm trong chương trìnhnghị sự của OECD và Ngân hàng Thế giới sẽ giúp:

• Trách nhiệm giải trình: Cần thiết phải rõ ràng trong việc sử dụng các quỹ như thế nào để nhữngngười đại diện và quan chức phải chịu trách nhiệm về tính hiệu quả và năng suất.

• Sự toàn vẹn: "Sunlight"là chính sách tốt nhất để ngăn chặn tham nhũng và duy trì các tiêu chuẩncao về toàn vẹn trong việc sử dụng các quỹ công.

14

Page 15: Whitepaper Request Network T÷ìng lai cıa th÷ìng m⁄i M⁄ng l ...Whitepaper Request Network T÷ìng lai cıa th÷ìng m⁄i M⁄ng l÷îi y¶u cƒu thanh to¡n phi t“p trung

• Sự bao hàm: Sự minh bạch là tạo điều kiện cho một cuộc tranh luận có tính thông tin và toàn diệnvề những tác động của chính sách ngân sách.

• Niềm tin: Chúng ta đang sống trong kỉ nguyên của các dự án nguồn mở và sự hợp tác, sự minh bạchthúc đẩy sự tin tưởng vào một xã hội mà quan điểm và lợi ích của người dân được tôn trọng và tiềnquỹ công được sử dụng một cách hợp lý.

• Chất lượng: BKiểm tra ngân sách, như việc kiểm tra mã lập trình, cho phép phát hiện ra sự lãng phí,lạm dụng và chỉ ra cách cải thiện kết quả cho hiệu quả hơn.

Request đề xuất một khuôn khổ cho phép các tổ chức này đạt được tính minh bạch một cách thuận tiện,thông báo thông tin tài khoản của họ theo thời gian thực và đến bất cứ ai để đối chiếu và sử dụng các dữliệu này. Khi khuôn khổ này trở nên phổ biến, nhiều công cụ sẽ được phát triển, ví dụ như một bảng kê khaivề chi phí hoạt động của thành phố chúng ta.

4.7 IoT và hợp đồng thông minh

Một thách thức thú vị trong những năm tới chắc chắn sẽ là cách mà các vật thể, máy móc và trí tuệ nhântạo sẽ tương tác với nhau, tự động thương lượng và xác định các điều kiện thanh toán. Lúc này chúng sẽ cầnmột khuôn khổ thanh toán để xác định các lý do và điều kiện giao dịch.

Thử tưởng tượng một chiếc xe hơi tự lái tự đặt hàng một bánh xe mới tại một ga-ra ảo, đặtcọc và thanh toán 90% còn lại khi giao hàng.

5 Token

Mặc dù được xây dựng trên nền tảng sổ cái blockchain của Ethereum, Request hướng đến sự độc lập với cácloại tiền tệ khác, các chính sách tiền tệ hoặc các lựa chọn công nghệ để xây dựng một hệ thống mạnh mẽnhất có thể. Chúng tôi tin điều này là thiết yếu để đi lên với một cộng đồng đang được mở rộng và việc pháttriển một hệ sinh thái xung quanh cơ cấu của chúng tôi, nơi mà ngày càng có nhiều DAPP (Ứng dụng phânquyền) được tạo ra.

5.1 Khuyến khích một hệ sinh thái các ứng dụng an toàn

Mã thông báo (token) REQ là các mã thông báo ERC-20 dùng để tham gia mạng lưới, tạo các Request nângcao và để thưởng cho các bên khác nhau giúp xây dựng hệ sinh thái yêu cầu thanh toán.Khi sử dụng mạng lưới, những người tham gia sẽ phải trả một khoản phí mạng bằng REQ để khấu hao.Việc khấu hao các mã thông báo này có thể làm tăng nhu cầu cho các REQ còn lại. Chi phí sẽ được điềuchỉnh bởi các nhà vận hành Request Network tùy thuộc vào việc sụt giảm nguồn cung cấp REQ cũng nhưtỷ giá so với các loại tiền tệ được phép trên mạng lưới.

Ví dụ, một yêu cầu của hệ thống vào giai đoạn đầu có thể tiêu tốn 10 REQ trong tổng nguồn cung là1.000.000.000 REQ. Khi hệ thống đã được sử dụng một thời gian, một Request có thể chỉ tiêu tốn 0,0001REQ trên tổng số 100.000 REQ.

Mạng lưới sẽ được tích hợp một hệ thống để thưởng cho các nền tảng có tính phí bằng REQ xây dựngtrên giao thức này. Bằng cách này, chúng tôi mong muốn tạo ra một nền tảng tài chính mở hoàn toàn.

Chi phí dự kiến cho nền tảng này là từ 0,05% đến 0,5% giá trị của các giao dịch. Phí này sau đó sẽ giảmkhi khối lượng giao dịch tăng lên để duy trì tính cạnh tranh và giảm thiểu đối thủ thay thế. Với việc chuyểntiền trên thị trường toàn cầu hơn 5.000 tỷ đô la mỗi ngày, chỉ một khoản phí tối thiểu cũng đã đủ khi nền

15

Page 16: Whitepaper Request Network T÷ìng lai cıa th÷ìng m⁄i M⁄ng l ...Whitepaper Request Network T÷ìng lai cıa th÷ìng m⁄i M⁄ng l÷îi y¶u cƒu thanh to¡n phi t“p trung

tảng này phát triển với quy mô lớn hơn.

5.2 Quản trị

Chúng tôi có một khao khát mạnh mẽ để xây dựng một hệ thống Request phát triển và tồn tại hàng chụchoặc thậm chí hàng trăm năm. Một hệ thống mà ở đó không chỉ các nhà sử học có thể sử dụng đểbiết được thương mại điện tử đã diễn ra như thế nào trong thế kỷ 21, mà còn là một hệ thống sẽđưa chúng ta vào tương lai, với sức mạnh và cấu trúc được sử dụng khi máy móc và trí tuệ nhân tạo sẽ thựchiện phần lớn các giao dịch.Vì lý do này, Request sẽ phải thực sự linh hoạt và dễ dàng mở rộng. Đây là một trong những thách thứcchính của các hệ thống phân tán (như chúng ta có thể thấy với Bitcoin14 Segwit, hoặc bộ quản lý Ice Agecủa Ethereum v.v). Chúng tôi muốn tách riêng sự quản trị của cộng đồng khỏi Ethereum và tránh sự phụthuộc cho phép mọi chủ sở hữu mã thông báo (token) Ethereum quyết định về tương lai của cộng đồng này15.

REQ sẽ khiến cho cộng đồng xích lại với nhau và cho phép thảo luận cũng như bình chọn các quyết địnhquan trọng trong tương lai. Cả cộng đồng sẽ là một hội đồng quản trị và chúng tôi sẽ tạo ra các công cụ cầnthiết cho ban quản lý này: Một hệ thống bỏ phiếu đồng thời cũng có thể là một hệ thống trò chuyện dànhriêng cho các thành viên của hội đồng quản trị này.

5.3 Độc lập với các loại tiền tệ khác

Request độc lập với mọi loại tiền tệ và không phụ thuộc vào bất kỳ chính sách tiền tệ nào. Request cần phảitrở nên miễn nhiễm tối đa với sự lạm phát hoặc giảm phát của ETH. Lộ trình của Ethereum hỗ trợ hướngphát triển của chúng tôi, với khả năng cao là những người đào (miner)/người nắm cổ phần (staker) sẽ nângcấp lên Casper để chấp nhận mã thông báo (token) ERC20, đây sẽ là một sự đơn giản hóa tuyệt vời.Sự độc lập này sẽ cho phép Request nâng cấp sang một hệ thống với công nghệ mới mà vẫn giữ nguyên hệsinh thái cho chủ sở hữu mã thông báo (token).

5.4 Độc lập về kỹ thuật

Trong quá trình mở rộng Request Network, có khả năng cao rằng chúng ta sẽ sử dụng một giải pháp nhưPlasma Chains. Trong các giải pháp này, một mã thông báo (token) cụ thể giúp khuyến khích việc tránhtrạng thái Byzantine16 và tối đa hóa an ninh. Mã thông báo (token) này được sử dụng như là một POS(Proof of Stake – chứng nhận sở hữu) và khiến người nắm cổ phần (staker) từ bỏ ý định thực hiện hành viByzantine vì nó có thể làm giảm giá trị của mã thông báo (token).Sử dụng mã thông báo (token) là cách linh hoạt và độc lập nhất để khái niệm hoá một hệ thống cần mà nósẽ cần sự đồng thuận và an ninh để phát triển trong dài hạn17.

5.5 Đơn giản hóa trao đổi liên tiền tệ

Chúng tôi sẽ đề xuất một mô hình mà các vòng lặp của các hoá đơn có thể được xác định tự động bởi hệthống và quyết toán mà không đòi hỏi sự thay đổi quỹ. Ví dụ, nếu Alice nợ tiền Bob, Bob nợ tiền Charlie,người nhận được Request thanh toán từ Alice, hệ thống có thể đề xuất bù trừ cho các hóa đơn này và REQsẽ giải quyết các khoản chênh lệch.

14https://bitcoin.org/bitcoin.pdf, 2008, Satoshi Nakamoto15https://medium.com/@FEhrsam/scaling-ethereum-to-billions-of-users-f37d9f487db1, 06/27/2017, Fred Ehrsam16http://www.scs.stanford.edu/14au-cs244b/labs/projects/copeland_zhong.pdf, 2016, Christopher Copeland and

Hongxia Zhong17http://plasma.io/plasma.pdf

16

Page 17: Whitepaper Request Network T÷ìng lai cıa th÷ìng m⁄i M⁄ng l ...Whitepaper Request Network T÷ìng lai cıa th÷ìng m⁄i M⁄ng l÷îi y¶u cƒu thanh to¡n phi t“p trung

6 Bản thảo lộ trình

Request Pyramid: Quý 3 / 2017-Đưa ra dự thảo cuối cùng của white paper.-Khai trương trang web của Request Network.

Request Colossus: Quý 4 / 2017-Mở bán mã thông báo (token).-Phiên bản đầu tiên của Request hoạt động với Ethereum trên Test Net.-Thử nghiệm: Request Core làm việc với một Bitcoin Oracle.-Cung cấp API để tạo/đọc/cập nhật Request.-Cung cấp bài báo kỹ thuật về kiến trúc, nâng cấp và xây dựng quy trình kế toán.

Request Great Wall: Quý 1 / 2018-Phiên bản đầu tiên của Request hoạt động với Ethereum trên Main Net.-Quản lý việc triển khai các loại tiền tệ mã hóa trên Request (ERC20 tokens).-Triển khai trang web để tạo/trực quan hóa và tương tác với Request.-Thêm bộ quản lý của Request trên các khái niệm kế toán như hoàn tiền, ghi nợ tín dụng và đơn đặt hàng.-Hợp tác với các công ty kế toán, thanh toán và kiểm toán.-Khởi động dự án “Thanh toán với Request”: một giải pháp trực tuyến thay thế cho những phương pháptruyền thống như “Thanh toán với Paypal” và “Thanh toán bằng thẻ tín dụng”.- Kiểm toán bên ngoài cho Request Contracts.

Request Stonehenge: Quý 2 / 2018-Thử nghiệm mở rộng Request thông qua chuỗi Plasma với PoS. Request sẽ phải xử lý được một khối lượnglớn các giao dịch.-Thử nghiệm để tăng tính riêng tư của Request sử dụng ZkSnarks18.-Thêm quản lý tiền tệ fiat trên Request (USD, EUR, CNY).-Khởi động dự án “Request and sự minh bạch”. Chúng tôi sẽ làm việc với các chính quyền thành phố, hiệphội và chính phủ để cập nhật thông tin về ngân sách theo thời gian thực.-Tổ chức các nhóm thảo luận xung quanh Payment Request với các tổ chức như Worldbank / IMF / ECBvà Liên Hợp Quốc.

Request Colosseum: Quý 3 / 2018-Triển khai tiện ích Ký quỹ (Escrow) để cho phép giải ngân khi giao hàng hoặc khi đáp ứng các điều kiệnkhác.-Triển khai tiện ích Thuế (Tax) để tự động trả thuế.-Triển khai tiện ích Đặt cọc (Down payment) để xác định số tiền phải trả vào một ngày cụ thể.-Triển khai tiện ích Phí trả chậm (Late Fees) để xác định hình phạt nếu một doanh nghiệp không được thanhtoán đúng hạn.-Thêm một lớp Danh tiếng ngoại chuỗi (Reputation Offchain).

Request Petra: Quý 4 / 2018 trở về sau-Triển khai hệ thống quản trị (Vote / Token Chat).-Khởi động dự án "Internet of Things Framework".-Triển khai thanh toán ngoại tệ thông qua REQ để tạo điều kiện cho thanh toán quốc tế.-Khởi động tiện ích Thanh toán Liên tục (Continuos Payment) đóng vai trò như một khoản Đặt cọc (Downpayement) với vô số khoản trả nhỏ hơn.

18https://medium.com/@VitalikButerin/zk-snarks-under-the-hood-b33151a013f6, 2017, Vitalik Buterin

17

Page 18: Whitepaper Request Network T÷ìng lai cıa th÷ìng m⁄i M⁄ng l ...Whitepaper Request Network T÷ìng lai cıa th÷ìng m⁄i M⁄ng l÷îi y¶u cƒu thanh to¡n phi t“p trung

7 Đội ngũ

7.1 Nhóm chính

Nhân lực là tài sản mạnh nhất của chúng tôi cho dự án Request. Tất cả các thành viên đã làm việc cùngnhau trong quá khứ, với thời gian khác nhau từ 6 tháng đến 6 năm. Chúng tôi là những người thích hànhđộng. Kinh nghiệm của chúng tôi về tài chính, blockchain và kinh doanh được kết hợp để thiết lập lại tổ chứcthương mại quốc tế của tương lai.

Chúng tôi là ai?

Đội ngũ của chúng tôi bao gồm: giám đốc tài chính, quản lý CNTT, kiểm toán viên tài chính, kế toán,quản lý điều hành, thủ quỹ, chuyên gia phân tích dữ liệu, lập trình viên front end, back end, lập trình viêntrưởng và và lập trình viên blockchain. Các vị trí này đều giàu kinh nghiệm trên nhiều lĩnh vực như tư vấn,tài chính, dược phẩm, âm nhạc, nghiên cứu và fintech.

Chúng tôi chuyên về blockchain, fintech và các điều khoản tài chính và chúng tôi tin rằng có nhiều phươngpháp thay thế minh bạch và bền vững hơn cho hoạt động ngân hàng ngày nay. Kinh nghiệm của chúng tôitrong việc thúc đẩy ngân hàng ING ở Amsterdam, cuộc thi Lisbon Challenge ở Bồ Đào Nha và YCombinatorở Thung lũng Silicon, cũng như kinh nghiệm cá nhân của chúng tôi ở Trung Quốc, Hoa Kỳ, Thụy Sĩ vàMexico, tất cả đều phản ánh phong cách chuyên nghiệp và lối tư duy toàn cầu của chúng tôi. Chúng tôi tinvào sự tự do di chuyển, làm việc từ xa và tự do, không chỉ cho các cá nhân và các doanh nghiệp, mà còn chomáy móc, tiền bạc và thông tin.

Tại sao lại là Request?Trong quý đầu tiên của năm 2017, đội ngũ chúng tôi đã tham gia YCombinator ở San Francisco. Chúng tôiđã trao đổi với những startup tương lai lớn nhất và các nhà đầu tư danh tiếng ở Thung lũng Silicon và tất cảđều đồng ý rằng blockchain là phương tiện tốt nhất để xây dựng nền tảng cho thương mại quốc tế. Khi màngày nay các dịch vụ đang phải vật lộn để giải quyết các vấn đề của ngân hàng và ban quản lý, blockchainmang lại một giải pháp triệt để. Với Request, các vấn đề thanh toán trong nước và quốc tế hầu như khôngcó, tất cả được sắp xếp xuyên suốt và tự động.

Dự án bắt đầu khi nào?Năm 2014, nhóm đã nghiên cứu xây dựng một mạng lưới chuyển tiền quốc tế dựa trên Bitcoin mang tênMoneytis, và dần dần phát triển thành một mạng lưới thanh toán toàn cầu bao hàm các giải pháp chuyểntiền và cho phép thực hiện giao dịch đến vài triệu đô la hàng tháng.Từ 2014 đến 2017, nhóm đã phát triển destinesia.io, theblockchainnetwork.com, neomy.io và moneytis.com.Những nghiên cứu dựa trên tính mở rộng và tính thanh khoản của giải pháp blockchain cho việc chuyển tiềnđã gặt hái nhiều thành công và chúng tôi học hỏi được nhiều từ người dùng, các công ty, freelancer và cáccá nhân khác.

Trình bày của các thành viên trong nhóm:

Etienne Tatur, Giám đốc Công nghệ (CTO)Etienne là một "người đam mê blockchain", tốt nghiệp trường kỹ sư Pháp, INSA Lyon. Anh gặp Christophetại Amaris vào tháng 4 năm 2011 tại Geneva (Thụy Sĩ), nơi anh là trưởng nhóm phát triển và quản lý cácdự án CNTT. Tại đó, anh đã chia sẻ về niềm đam mê blockchain của mình, trước khi trở thành CTO. Saukinh nghiệm tại Qobuz (startup về âm nhạc), vào năm 2014, anh đã tạo ra dự án blockchain đầu tiên củamình "Snapsoko"sau đó đổi tên thành The Blockchain Network, và được tích hợp vào dự án Moneytis. Đâycũng là nhà sản xuất Messenger Bot Neomy.io.Anh đã có bài thuyết trình về các mối liên kết giữa blockchain và chuyển tiền trong hội nghị Chuyển TiềnQuốc Tế tại Miami, và trong hội nghi Blockchain France và Visa Europe ở Paris.Chuyên gia Blockchain của chúng tôi luôn hứng thú với các công nghệ mới, nhiếp ảnh và leo núi. Anh làthành viên của La Chaintech và cho rằng Blockchain sẽ thay đổi thế giới.

18

Page 19: Whitepaper Request Network T÷ìng lai cıa th÷ìng m⁄i M⁄ng l ...Whitepaper Request Network T÷ìng lai cıa th÷ìng m⁄i M⁄ng l÷îi y¶u cƒu thanh to¡n phi t“p trung

Christophe Lassuyt, Giám đốc Tài chính (CFO)Christophe Lassuyt có kinh nghiệm làm giám đốc tài chính quốc tế từ Bắc Mỹ, Châu Âu cho đến Châu Á.Sau khi tốt nghiệp trường quản trị kinh doanh (NEOMA Business School), anh bắt đầu với vị trí kiểm soátquản trị máy tính (computer management controller), trước khi trở thành giám đốc tài chính quốc tế tạiAmaris và Virtua. Anh là thành viên hiện của phong trào Mangrove. Anh tin rằng làm việc và đi du lịchcùng một lúc mang lại năng suất cao.Khi bắt đầu làm Giám đốc Tài chính (CFO), Christophe đã tự thu xếp tất cả các hoạt động kinh doanh chomột chi nhánh của Amaris tại Munich, Đức, bao gồm thực hiện kế toán cho khách hàng; kế toán cho nhàcung cấp; kho bạc; kiểm toán nội bộ; quan hệ với kiểm toán viên bên ngoài; giám sát kiểm toán thuế; Kiểmsoát quản lý v.v. Kiến thức của anh bao gồm thời gian xử lý của một hoá đơn, các vấn đề chuyển nhượng nợ(factoring), và thành tích lớn nhất của anh là tự động hóa được các giao dịch này trong các công ty mà anhtừng làm việc, với một tỷ lệ của một người làm với năng suất của 300 nhân viên.Anh quan tâm nhất đến các vấn đề liên quan đến việc thanh toán hóa đơn. Ví dụ, giả sử rằng một thư kýnhận một hoá đơn qua email, được xác nhận với người quản lý, và sau đó gửi cho kế toán viên. Kế toánviên phải nhập nó vào một chương trình phần mềm, trước khi xử lý khoản thanh toán, cũng phải xác nhậnbởi một người quản lý. Quá trình này là tốn thời gian không cần thiết, trong khi đó không xa, với Request,chúng ta có thể nhận được hóa đơn đó qua smartphone và thực hiện một thao tác duy nhất có / không đểviệc thanh toán diễn ra tự động đúng vào ngày đáo hạn.

Vincent Rolland, Kỹ sư back-end, Lập trình viên SolidityVincent tốt nghiệp trường danh giá INSA Lyon tại Pháp với nền tảng nghiên cứu và làm việc cho CNRSliên kết với trường đại học Stanford. Anh cũng tham gia hợp tác trong dự án khoa học ở bảo tàng lịch sử tựnhiên Paris. Sau đó, anh gia nhập Moneytis trong dự án mạng lưới Blockchain cho chuyển tiền quốc tế vàcũng đã cải tiến dự án neomy.io bằng các tự động hóa nó theo góc nhìn của nghiên cứu và phát triển.Vincent hướng tới việc mang lại sự minh bạch và giá trị cho các dự án của mình. Request là một cơ hội tuyệtvời để cung cấp sự minh bạch trên mức độ toàn cầu.

Elliott Denis, Kỹ sư full stackElliott là một kỹ sư full stack. Công việc của anh làm sao lập trình một cách gọn gàng, thanh lịch và hiệu quảbằng cách tích hợp công nghệ web hiện đại nhất. Anh phát hiện ra Ethereum lần đầu tiên vào năm 2016 vàtừ đó đã không ngừng cố gắng để tìm hiểu các ứng dụng của nó. Đầu tiên với Moneytis và sau đó với dự ánRequest, anh tin rằng mình có thể mang lại sự đơn giản và minh bạch cho thương mại thế giới trong tương lai.

Laura Girod, Chuyên gia Quản lý Tài chính và Phân tích Dữ liệuTốt nghiệp trường Kinh doanh ICN, Laura từng đóng vai trò kiểm toán viên nội bộ, kiểm soát tài chính,phân tích dữ liệu, và thậm chí là hỗ trợ khách hàng. Cô đã làm chủ hệ thống kế toán và kiểm toán và làmviệc trong vòng vài năm tại một startup quốc tế tại Thụy Sĩ và Châu Á, trước khi gia nhập Moneytis vàotháng 12 năm 2015.Nhờ tài năng của cô trong thống kê và lên mô hình, cô đã tạo ra thuật toán sympathetic cho neomy.io.

Julien Devoir, CMO HipsterJulien có nhiều kinh nghiệm trong lĩnh vực tăng trưởng thị trường và thiết kế đồ họa. Anh đã tham gia vàoYCombinator tại Moneytis. Anh là một trong những thành viên đầu tiên của phong trào Mangrove.Julien đã tự học về tiếp thị số (digital marketing) và các công nghệ mới. Niềm đam mê dành cho internetthúc đẩy anh trở thành một Growth Hacker tại Virtua (Thụy Sĩ) và Molotov.tv (Pháp).Theo Julien, làm việc và đi du lịch đồng thời làm sẽ tăng năng suất làm việc. Anh cho rằng ta cũng có thểhọc hỏi khi đi du lịch và đã khuyến khích điều này bằng cách đồng sáng lập dự án destinesia.io.

19

Page 20: Whitepaper Request Network T÷ìng lai cıa th÷ìng m⁄i M⁄ng l ...Whitepaper Request Network T÷ìng lai cıa th÷ìng m⁄i M⁄ng l÷îi y¶u cƒu thanh to¡n phi t“p trung

8 Kiến trúc

Chúng tôi sẽ sớm công bố một Yellow paper về chi tiết các thông số kỹ thuật. Mục đích của phần này nhằmđưa ra một số gợi ý về thách thức mà chúng tôi phải đối mặt và kiến trúc đã chọn.

Request là một dịch vụ giao thức với một số lượng lớn các ứng dụng dựa trên nó, hướng tới hoàn toànkhông thông qua máy chủ, mã nguồn mở và phân cấp. Để đạt được mục tiêu này, chúng tôi đã quyết địnhxây dựng Request trên nền công nghệ Ethereum.

Ethereum: Ethereum cho phép thực hiện Hợp đồng Thông minh (Smart Contract) một cách phân quyềntrên EVM, khiến cho Request đạt được tính phân cấp và không thông qua máy chủ. Hợp đồng thông minhcủa Request được phát triển theo Solidity. Request sử dụng Ethereum để tạo hóa đơn và tự động phát hiệnthanh toán.

Swarm và Filecoin: Swarm19 và Filecoin20 cho phép tài liệu lưu trữ được phân cấp trong một mạngphân phối. Filecoin sẽ lưu giữ thông tin nặng nhất của hóa đơn và Swarm lưu những gì cần phải được truycập một cách nhanh nhất, chẳng hạn như một số metadata.

8.1 Các cân nhắc kỹ thuật

Chính sách bảo mậtQuản lý bảo mật là một trong những thách thức và ưu tiên của giao thức Ethereum. Việc sử dụng ZkSnarks21

(Zero Knowledge succinct non-interactive arguments of knowledge) giải quyết vấn đề này. ZkSnarks là mộtphần của lộ trình Ethereum nhưng nó sẽ không được thực hiện ngay.Cho đến khi việc ra đời chính thức của ZkSnarks hoặc giải pháp tương tự, chúng tôi sẽ làm việc theo 3 hướn:-Cho phép các yêu cầu công khai -Giới thiệu khái niệm các yêu cầu cơ bản. Một loại Request sẽ không phải làhợp đồng thông minh mà được mã hóa hash trên Filecoin -Chuỗi Plasma. Chuỗi Plasma sẽ cho phép ZkSnarksvà chúng tôi đang theo dõi chặt chẽ Omise để làm việc với chúng -Cuối cùng là một sidechain tạm thời sử dụngQuorum22 và các giao dịch cá nhân kết nối với một giao dịch công khai thông qua một hệ thống như Polkadot23

Khả năng mở rộng Khả năng mở rộng cũng là một thách thức khác đối với các blockchains, và hiểnnhiên chúng tôi mong muốn hỗ trợ một số lượng giao dịch rất lớn. Thực tế là chúng ta có thể quản lý nhiều loạitiền tệ sẽ làm cho số lượng giao dịch Request tăng trưởng nhanh hơn số lượng các giao dịch Ethereum. Đây làlý do tại sao một số đổi mới trong lộ trình Ethereum sẽ rất quan trọng cho Request, chẳng hạn như Sharding24.

Sharding vẫn còn một chặng đường dài phía trước, do đó chúng tôi sẽ phát triển về:-Cho tải tối đa chuỗi ngoài (off chain) trên Plasma / State-channels25

-Một số Request cơ bản cho số lượng ít, mà không phải là hợp đồng thông minh, được tập hợp trên Filecoinvà Swarm.

19https://github.com/ethersphere/swarm, 03/22/201720https://filecoin.io/filecoin.pdf, 08/04/2017, Protocol Labs21https://blog.ethereum.org/2016/12/05/zksnarks-in-a-nutshell/, 12/05/2016, Christian Reitwiessner22https://github.com/jpmorganchase/quorum-docs/blob/master/Quorum%20Whitepaper%20v0.1.pdf, 11/22/201623https://github.com/w3f/polkadot-white-paper/, 11/10/2016, Dr. Gavin Wood24https://github.com/ethereum/wiki/wiki/Sharding-FAQ, Vitalik Buterin. Ethereum Sharding FAQ25https://raiden.network/, Raiden. Raiden Network

20

Page 21: Whitepaper Request Network T÷ìng lai cıa th÷ìng m⁄i M⁄ng l ...Whitepaper Request Network T÷ìng lai cıa th÷ìng m⁄i M⁄ng l÷îi y¶u cƒu thanh to¡n phi t“p trung

8.2 Kiến trúc hợp đồng thông minh

Tổng quan về các hợp đồng thông minh. Phần nhân đang đăng kí tất cả các Request, có thể quản lý đượcnhằm cho phép cập nhật và tạm dừng. Chỉ có một nhân duy nhất và nhân này có thể cho phép các hợp đồngphụ quản lý từng loại tiền tệ. Mỗi hợp đồng phụ quản lý việc tạo ra và tương tác với yêu cầu cho một loạitiền tệ cụ thể. Một số hợp đồng phụ có thể đồng bộ, trong khi những hợp đồng khác tương tác với một oracle

(ví dụ như các loại tiền tệ Fiat).

21

Page 22: Whitepaper Request Network T÷ìng lai cıa th÷ìng m⁄i M⁄ng l ...Whitepaper Request Network T÷ìng lai cıa th÷ìng m⁄i M⁄ng l÷îi y¶u cƒu thanh to¡n phi t“p trung

Trên đây là chi tiết của một hợp đồng phụ về tiền tệ. Hợp đồng phụ tương tác với các phần tiện ích mở rộngkhác nhau có thể được được chọn bởi người tạo yêu cầu.

9 Cảm ơn

Chúng tôi xin cảm ơn những người đánh giá sau đây đã có đóng góp và phản hồi cho việc hoàn thành tàiliệu này hoặc giúp chúng tôi thông qua các phần khác nhau của dự án:Nadja Benes - GnosisAntoine Grebert - QuandooYoann Marion - AmarisAndria Antoniou - Tiến sĩ tại PiGPierre Laurent - người đam mê BlockchainChristopher BarryNguyen Khoi Nguyen - Bản dịch tiếng Việt

22

Page 23: Whitepaper Request Network T÷ìng lai cıa th÷ìng m⁄i M⁄ng l ...Whitepaper Request Network T÷ìng lai cıa th÷ìng m⁄i M⁄ng l÷îi y¶u cƒu thanh to¡n phi t“p trung

10 Trích dẫn

1. http://gavwood.com/paper.pdf, 2014, Gavin Wood. Ethereum: a secure decentralised generalised trans-action ledger

2. https://github.com/ethereum/wiki/wiki/White-Paper

3. https://www.fincen.gov/sites/default/files/shared/Appendix_D.pdf

4. https://ipfs.io/ipfs/QmXoypizjW3WknFiJnKLwHCnL72vedxjQkDDP1mXWo6uco/wiki/Double-entry_bookkeeping_system.html, 11/25/2016

5. http://iang.org/papers/triple_entry.html, 2005, Ian Grigg

6. http://ww2.cfo.com/expense-management/2015/06/metric-month-accounts-payable-process-cost/,06/24/2015, Mary Driscoll

7. https://bitcoin.org/bitcoin.pdf, 2008, Satoshi Nakamoto

8. https://medium.com/@FEhrsam/scaling-ethereum-to-billions-of-users-f37d9f487db1, 06/27/2017,Fred Ehrsam

9. http://www.scs.stanford.edu/14au-cs244b/labs/projects/copeland_zhong.pdf, 2016, Christo-pher Copeland and Hongxia Zhong

10. https://medium.com/@VitalikButerin/zk-snarks-under-the-hood-b33151a013f6,2017, VitalikButerin

11. https://github.com/ethersphere/swarm, 03/22/2017

12. https://filecoin.io/filecoin.pdf, 08/04/2017, Protocol Labs

13. https://blog.ethereum.org/2016/12/05/zksnarks-in-a-nutshell, 12/05/2016, Christian Reitwiess-ner

14. https://github.com/jpmorganchase/quorum-docs/blob/master/Quorum%20Whitepaper%20v0.1.pdf, 11/22/2016

15. https://github.com/w3f/polkadot-white-paper/, 11/10/2016, Dr. Gavin Wood

16. https://github.com/ethereum/wiki/wiki/Sharding-FAQ

17. https://raiden.network/

23