3 ms·

These conversations are always so vague that one has to wonder if it's deliberate. I'd love it if the discussion could get more concrete. For example, what's a

These conversations are always so vague that one has to wonder if it's deliberate. I'd love it if the discussion could get more concrete. For example, what's a specific case of international trade fraud that a blockchain could have prevented, and why is a blockchain needed to prevent it?

mike_hearn 4y ago
It's not deliberate, it's just a huge topic. I spent years learning about it because I worked on the underlying platform that's used in several competitors to TradeLens: https://corda.net/global-trade/ https://corda.net/global-trade/ Trade Finance 101 - two companies in very different parts of the world want to trade for some non-trivial sum of money, e.g. buying a shipment of goods. You'd think this would be simple but it's really not. The two parties often do not actually trust one another, in particular they may have very little visibility into mundane things like the insolvency risk of their counterparties. This is an actual problem because in the physical world you can't atomically swap things for money, so someone is going to have to either pay first or deliver first. If you pay and then the seller doesn't deliver, that may cause you to go under. If the seller ships and you never pay, ditto in reverse. So the importer may go to their bank and request a "letter of credit", which is basically a form of escrow in which the importer's bank will guarantee to pay on presentation of proof of delivery e.g. bills of lading. They may also help arrange things like a maritime insurance policy, they have expertise in how to handle shipping disputes and so on. Often the importer's bank will send these documents direct to the exporters bank because the exporter may need a short term loan to cover the cost of actually making the goods. But the exporter is just receiving literally a bundle of physical documents in many cases, and the loans in question can be large, so they are vulnerable to document forging. Forged trade finance documents are actually a major source of AML problems and fraud. Then you have to actually ship it. That's more documents and payments to the shipping companies, to get your goods cleared at customs, dealing with freight forwarders etc. And so on and so forth. Long story short: documents everywhere, most of which aren't even in any sort of real data format (e.g. PDFs are common) and some of which aren't even in computers at all, depending on where you're dealing with! In the world of enterprise logistics there are very few properly digitized systems, because it's very hard to get everyone in the world to agree to just use some arbitrary SaaS app. You can try, and companies like Flexport are doing it, but the players in all of these transactions are (a) very conservative, and (b) very reluctant to lock in something as fundamental as their ability to import/export to the fate of some random American VC backed startup. And for good reason! Imagine if they'd all jumped on board such a company but instead of a US firm providing the centralized SaaS it was, for example, Russia. Now imagine the global trading SaaS has an outage, or gets hacked. Or simply raises prices. So what to do? The actual answer settled on by the world's trading and logistics people is ... do nothing. Stick with the faxes and couriers. Or at best you get an ad-hoc patchwork of individual systems between specific counterparties. Enter the enigma called "enterprise blockchain" or sometimes distributed ledger technology. These platforms may or may not actually have blocks, chains, proofs of work or tokens in them. The one I designed (Corda) has none of these things albeit there's a "tokens framework" if you want to create such things on top of the core. What these platforms are actually trying to do is provide standardized mechanisms for: 1. Inter-firm identity (fairly standard X.500 PKIX in the case of Corda) 2. Inter-firm messaging that isn't SWIFT (AMQP+client/server TLS in Corda), and really you also need inter-firm state machines and protocol frameworks (the "flow framework" in Corda, which uses a JVM coroutine library). 3. Serialization of signed data structures (AMQP+extensions) 4. The really hard bit: signed, irrefutable inter-firm transactions with data integrity, with some reasonably acceptable level of privacy. Think P2P tables, stored procedures, foreign key constraints and so on but in which you're not allowed to actually show the full transaction to anyone at any point including the tx ordering subsystem. The latter part is where the blockchain-y aspects enter the picture although in reality they don't normally use proof of work or stake. In Corda it's pluggable and some projects just use Raft. Others can simply use an RDBMS to provide 'double spend' protection. And there's also a BFT plugin I think, although I'm not sure if it ever launched (they're doing a big rewrite of the platform at the moment). It's pluggable because what we found is that participants often had rather complicated trust models in which they were very concerned with things like data integrity losses due to mistakes/botched upgrades, passive adversaries (competitors, foreign governments), not so concerned with active adversaries and very concerned with availability/DoS attacks of various kinds including political DoS. This makes sense given their environment, in which everyone is identifiable and basically follows the law but competitors may be tempted to 'peek' at data they weren't meant to see, and governments may be tempted to just ignore laws for geopolitical advantage sometimes. In an ideal world all this would be standardized and there'd be an ecosystem of vendors selling different implementations. In practice even just figuring out a design that all the different players can accept was a very hard challenge, making it work was harder still (decentralized asynchronous upgrades in particular were practically a research level problem), and Corda went the "open core" direction so other firms could just build off the open source code and data structures instead of having to re-implement it all from RFCs and other loose spec documents. That seemed to satisfy people. So anyway that's the background to these sorts of projects. They do make sense but are very hard to make work due to the massive variety of players, hard technical challenges and complex commercial/geo-political concerns.
- disqard 4y ago
  This is a fantastic inside look at this particular domain! Thank you for making time to write this up.
- dmitriid 4y ago
  I absolutely love the insight. I have some nitpick of course :) > just build off the open source code and data structures instead of having to re-implement it all from RFCs and other loose spec documents. It's never "just". What you're providing are exactly lose specs. E.g. "Serialization of signed data structures (AMQP+extensions)". What are the data structures? What do they look like? Which extensions? What happens if someone doesn't support all the extensions? RFCs and standards however bad they are exist for a reason. And even then people implement them poorly, or not at all. > hard to make work due to the massive variety of players, hard technical challenges and complex commercial/geo-political concerns. Unfortunately, in this list technical challenges should go last. For all the reasons you described in the first half of your message :)
  - mike_hearn 4y ago
    The data structures can be found in the code, but I agree it'd be better to have a spec. I tried to design it so one day such a spec could be written (lots of dependencies on pre-existing specs for example) but it never became a priority.
    - seymore_12 4y ago
      Majority of shipping/trading documents are formalized under EDIFACT standard for example, this is the layout of Bill of Lading/Shipping Instruction, so called IFTMIN https://service.unece.org/trade/untdid/d04a/trmd/iftmin_c.htm https://service.unece.org/trade/untdid/d04a/trmd/iftmin_c.ht... One of the possible reasons for TradeLens demise is that they choose to ignore them and came up with their own data structures (Json) i.e. partners that are usually EDIFACT capable had to practically start from scratch to comply with TradeLens format. At some point TradeLens realized that and started partially accepting EDI feeds, but it was too little, too late I guess.

mike_hearn 4y ago

It's not deliberate, it's just a huge topic. I spent years learning about it because I worked on the underlying platform that's used in several competitors to TradeLens: https://corda.net/global-trade/ https://corda.net/global-trade/ Trade Finance 101 - two companies in very different parts of the world want to trade for some non-trivial sum of money, e.g. buying a shipment of goods. You'd think this would be simple but it's really not. The two parties often do not actually trust one another, in particular they may have very little visibility into mundane things like the insolvency risk of their counterparties. This is an actual problem because in the physical world you can't atomically swap things for money, so someone is going to have to either pay first or deliver first. If you pay and then the seller doesn't deliver, that may cause you to go under. If the seller ships and you never pay, ditto in reverse. So the importer may go to their bank and request a "letter of credit", which is basically a form of escrow in which the importer's bank will guarantee to pay on presentation of proof of delivery e.g. bills of lading. They may also help arrange things like a maritime insurance policy, they have expertise in how to handle shipping disputes and so on. Often the importer's bank will send these documents direct to the exporters bank because the exporter may need a short term loan to cover the cost of actually making the goods. But the exporter is just receiving literally a bundle of physical documents in many cases, and the loans in question can be large, so they are vulnerable to document forging. Forged trade finance documents are actually a major source of AML problems and fraud. Then you have to actually ship it. That's more documents and payments to the shipping companies, to get your goods cleared at customs, dealing with freight forwarders etc. And so on and so forth. Long story short: documents everywhere, most of which aren't even in any sort of real data format (e.g. PDFs are common) and some of which aren't even in computers at all, depending on where you're dealing with! In the world of enterprise logistics there are very few properly digitized systems, because it's very hard to get everyone in the world to agree to just use some arbitrary SaaS app. You can try, and companies like Flexport are doing it, but the players in all of these transactions are (a) very conservative, and (b) very reluctant to lock in something as fundamental as their ability to import/export to the fate of some random American VC backed startup. And for good reason! Imagine if they'd all jumped on board such a company but instead of a US firm providing the centralized SaaS it was, for example, Russia. Now imagine the global trading SaaS has an outage, or gets hacked. Or simply raises prices. So what to do? The actual answer settled on by the world's trading and logistics people is ... do nothing. Stick with the faxes and couriers. Or at best you get an ad-hoc patchwork of individual systems between specific counterparties. Enter the enigma called "enterprise blockchain" or sometimes distributed ledger technology. These platforms may or may not actually have blocks, chains, proofs of work or tokens in them. The one I designed (Corda) has none of these things albeit there's a "tokens framework" if you want to create such things on top of the core. What these platforms are actually trying to do is provide standardized mechanisms for: 1. Inter-firm identity (fairly standard X.500 PKIX in the case of Corda) 2. Inter-firm messaging that isn't SWIFT (AMQP+client/server TLS in Corda), and really you also need inter-firm state machines and protocol frameworks (the "flow framework" in Corda, which uses a JVM coroutine library). 3. Serialization of signed data structures (AMQP+extensions) 4. The really hard bit: signed, irrefutable inter-firm transactions with data integrity, with some reasonably acceptable level of privacy. Think P2P tables, stored procedures, foreign key constraints and so on but in which you're not allowed to actually show the full transaction to anyone at any point including the tx ordering subsystem. The latter part is where the blockchain-y aspects enter the picture although in reality they don't normally use proof of work or stake. In Corda it's pluggable and some projects just use Raft. Others can simply use an RDBMS to provide 'double spend' protection. And there's also a BFT plugin I think, although I'm not sure if it ever launched (they're doing a big rewrite of the platform at the moment). It's pluggable because what we found is that participants often had rather complicated trust models in which they were very concerned with things like data integrity losses due to mistakes/botched upgrades, passive adversaries (competitors, foreign governments), not so concerned with active adversaries and very concerned with availability/DoS attacks of various kinds including political DoS. This makes sense given their environment, in which everyone is identifiable and basically follows the law but competitors may be tempted to 'peek' at data they weren't meant to see, and governments may be tempted to just ignore laws for geopolitical advantage sometimes. In an ideal world all this would be standardized and there'd be an ecosystem of vendors selling different implementations. In practice even just figuring out a design that all the different players can accept was a very hard challenge, making it work was harder still (decentralized asynchronous upgrades in particular were practically a research level problem), and Corda went the "open core" direction so other firms could just build off the open source code and data structures instead of having to re-implement it all from RFCs and other loose spec documents. That seemed to satisfy people. So anyway that's the background to these sorts of projects. They do make sense but are very hard to make work due to the massive variety of players, hard technical challenges and complex commercial/geo-political concerns.

disqard 4y ago
This is a fantastic inside look at this particular domain! Thank you for making time to write this up.
dmitriid 4y ago
I absolutely love the insight. I have some nitpick of course :) > just build off the open source code and data structures instead of having to re-implement it all from RFCs and other loose spec documents. It's never "just". What you're providing are exactly lose specs. E.g. "Serialization of signed data structures (AMQP+extensions)". What are the data structures? What do they look like? Which extensions? What happens if someone doesn't support all the extensions? RFCs and standards however bad they are exist for a reason. And even then people implement them poorly, or not at all. > hard to make work due to the massive variety of players, hard technical challenges and complex commercial/geo-political concerns. Unfortunately, in this list technical challenges should go last. For all the reasons you described in the first half of your message :)
- mike_hearn 4y ago
  The data structures can be found in the code, but I agree it'd be better to have a spec. I tried to design it so one day such a spec could be written (lots of dependencies on pre-existing specs for example) but it never became a priority.
  - seymore_12 4y ago
    Majority of shipping/trading documents are formalized under EDIFACT standard for example, this is the layout of Bill of Lading/Shipping Instruction, so called IFTMIN https://service.unece.org/trade/untdid/d04a/trmd/iftmin_c.htm https://service.unece.org/trade/untdid/d04a/trmd/iftmin_c.ht... One of the possible reasons for TradeLens demise is that they choose to ignore them and came up with their own data structures (Json) i.e. partners that are usually EDIFACT capable had to practically start from scratch to comply with TradeLens format. At some point TradeLens realized that and started partially accepting EDI feeds, but it was too little, too late I guess.