Transaction security on distributed-ledger based MaaS platform

1. A system, comprising:

a message broker device comprising circuitry configured to:

receive, from a first publisher node of a first transportation provider of a plurality of transportation providers, a first transaction request associated with a transport service; and

route, via an Application Programming Interface (API) gateway hosted on the message broker device, the first transaction request to a first subscriber node of the first transportation provider associated with the received first transaction request, wherein

the API gateway validates the routed first transaction request based on application of a set of security rules on the received first transaction request,

the first subscriber node is associated with a first node of a distributed ledger,

the first node stores a first state object that comprises transaction data associated with the transport service, and

the first node is configured to:

receive the validated first transaction request from the API gateway, via the first subscriber node; and

update the transaction data stored on the first node based on the received first transaction request.

2. The system according to claim 1 , wherein the first publisher node is one of a ride booking application, a ticketing gate, or a Point-of-Sale (PoS) of the first transportation provider.

3. The system according to claim 1 , wherein the distributed ledger includes a counter-party node as a Mobility-as-a-Service (MaaS) provider node associated with a MaaS provider.

4. The system according to claim 3 , further comprising a plurality of distributed ledgers associated with a plurality of MaaS providers, wherein each of the plurality of distributed ledgers includes the counter-party node as the MaaS provider node of a corresponding MaaS provider.

5. The system according to claim 1 , wherein the API gateway validates the routed first transaction request based on a determination that the routed first transaction request is associated with an Internet Protocol (IP) address amongst a valid range of IP addresses.

6. The system according to claim 1 , wherein the API gateway drops the routed first transaction request based on a determination that the routed first transaction request corresponds to a malicious behavior associated with a cyberattack.

7. The system according to claim 1 , wherein the API gateway drops the routed first transaction request based on a determination that the first publisher node is a bot.

8. The system according to claim 1 , wherein the API gateway validates the routed first transaction request based on a determination that the routed first transaction request is signed with a valid signature.

9. The system according to claim 1 , wherein the API gateway validates the routed first transaction request based on a verification of an authenticity and an authorization of the first publisher node.

10. The system according to claim 1 , wherein the set of security rules comprises one or more of:

a first rule to determine whether the routed first transaction request is associated with an Internet Protocol (IP) address amongst a valid range of IP addresses,

a second rule to determine whether the routed first transaction request corresponds to a malicious behavior associated with a cyberattack,

a third rule to determine whether the first publisher node is a bot,

a fourth rule to determine whether the routed first transaction request is signed with a valid signature, and

a fifth rule to validate the routed first transaction request based on a verification of an authenticity and an authorization of the first publisher node.

11. The system according to claim 1 , further comprising an API agent hosted on the first subscriber node, wherein the API gateway:

receives, from the API agent, an operational state associated with the first subscriber node,

wherein the received operational state indicates one of a scheduled maintenance, an accidental maintenance, or an unscheduled maintenance of the first subscriber node;

holds the routed first transaction request based on the received operational state; and

reroutes the first transaction request to the first subscriber node based on a determination that the operational state of the first subscriber node is active.

12. The system according to claim 1 , further comprising an API agent hosted on the first subscriber node, wherein the API agent is configured to:

receive the validated first transaction request via the API gateway; and

pass the validated first transaction request to the first subscriber node based on a determination that the validated first transaction request complies with information access policies of the first subscriber node,

wherein the information access policies comprise business rules and constraints associated with the transport service.

13. The system according to claim 1 , wherein the first node is further configured to:

receive the validated first transaction request from the API gateway, via the first subscriber node;

update the first state object based on a transaction message in the received first transaction request to output a second state object;

build a transaction comprising the first state object and the second state object;

sign the built transaction;

verify the signed transaction based on a determination that a first result of execution of a first smart contract included in the first state object matches a second result of execution of a second smart contract included in the second state object; and

share the verified transaction with a counter-party node.

14. The system according to claim 13 , wherein the counter-party node is configured to:

counter-sign the shared transaction; and

share the counter-signed transaction with the first node.

15. The system according to claim 14 , further comprising a consensus node configured to:

receive the counter-signed transaction from the first node;

notarize the received counter-signed transaction to include a signature of the consensus node; and

share the notarized transaction with the first node.

16. The system according to claim 15 , wherein the first node is configured to store the notarized transaction,

wherein the notarized transaction comprises the updated transaction data accessible to the first node and the counter-party node.

17. The system according to claim 1 , wherein the received first transaction request comprises one of a create message associated with a creation of the transport service for a user, a get-in message associated with a start of the transport service for the user, or a get-out message associated with completion of the transport service.

18. The system according to claim 1 , wherein the transaction data is associated with one or more of ticketing information, subscription information, payment information, revenue sharing information, or transport service information.

19. A method, comprising:

in a system comprising a message broker device, a first subscriber node, a first node of a distributed ledger, and an Application Programming Interface (API) gateway hosted on the message broker device:

receiving, by the message broker device, a first transaction request associated with a transport service,

wherein the first transaction request is received from a first publisher node of a first transportation provider of a plurality of transportation providers;

routing, by the message broker device, the first transaction request to the first subscriber node of the first transportation provider, via the API gateway;

validating, by the API gateway the routed first transaction request based on application of a set of security rules on the received first transaction request, wherein

the first subscriber node is associated with the first node of the distributed ledger, and

the first node stores a first state object that comprises transaction data associated with the transport service;

receiving, by the first node, the validated first transaction request from the API gateway, via the first subscriber node; and

updating, by the first node, the transaction data on stored the first node based on the received first transaction request.

20. The method according to claim 19 , wherein the set of security rules comprises one or more of:

a first rule to determine whether the routed first transaction request is associated with an Internet Protocol (IP) address amongst a valid range of IP addresses,

a second rule to determine whether the routed first transaction request corresponds to a malicious behavior associated with a cyberattack,

a third rule to determine whether the first publisher node is a bot,

a fourth rule to determine whether the routed first transaction request is signed with a valid signature, and

a fifth rule to validate the routed first transaction request based on a verification of an authenticity and an authorization of the first publisher node.

21. The method according to claim 19 , further comprising:

receiving, by the API gateway, an operational state associated with the first subscriber node, wherein

the operational state is received from an API agent is hosted on the first subscriber node, and

the received operational state indicates one of a scheduled maintenance, an accidental maintenance, or an unscheduled maintenance of the first subscriber node;

holding, by the API gateway, the routed first transaction request based on the received operational state; and

rerouting, by the API gateway, the first transaction request to the first subscriber node based on a determination that the operational state of the first subscriber node is active.

22. The method according to claim 19 , further comprising:

receiving, by an API agent, the validated first transaction request via the API gateway,

wherein the API agent is hosted on the first subscriber node; and

passing, by the API agent, the validated first transaction request to the first subscriber node based on a determination that the validated first transaction request complies with information access policies of the first subscriber node,

wherein the information access policies comprise business rules and constraints associated with the transport service.

23. The method according to claim 19 , further comprising:

receiving, by the first node, the validated first transaction request from the API gateway, via the first subscriber node;

updating, by the first node, the first state object to output a second state object based on a transaction message in the received first transaction request;

building, by the first node, a transaction comprising the first state object and the second state object;

signing, by the first node, the built transaction;

verifying, by the first node, the signed transaction based on a determination that a first result of execution of a first smart contract included in the first state object matches a second result of execution of a second smart contract included in the second state object; and

sharing, by the first node, the verified transaction with a counter-party node.