[HN Gopher] Cargill open-sources Splinter, its 'blockchain-like'...
___________________________________________________________________
Cargill open-sources Splinter, its 'blockchain-like' supply chain
software
Author : adrian_mrd
Score : 100 points
Date : 2021-01-22 07:20 UTC (1 days ago)
(HTM) web link (agfundernews.com)
(TXT) w3m dump (agfundernews.com)
| optimalsolver wrote:
| This indicates they've found little to no value in it.
| bnkamalesh wrote:
| https://dibizglobal.com would be an alternative
| high_density wrote:
| github link: https://github.com/Cargill/splinter
|
| written in rust :D
| bergstromm466 wrote:
| Something that really blew my hair back is hREA (formerly Holo-
| REA) - which is a combination of the Resources Events Agents
| (REA) accounting method, together with the distributed
| application framework holochain. It can help us move from
| corporate Enterprise Resource Planning software to follow
| (material) resources, to Network Resource Planning software,
| where all resources are stewarded in the commons based on open
| access and mutually consenting agreements/protocols. And
| holochain makes it all easily evolvable and unenclosable. It's
| one of the most exciting projects I've come across.
|
| hREA is aimed at creating a radically inclusive supply chain
| system. It is fully open source and being developed here:
| https://github.com/holo-rea/holo-rea
|
| This is a fun intro: http://mikorizal.org/futures.html
| slater wrote:
| Don't forget, Cargill is the worst company in the world:
|
| https://stories.mightyearth.org/cargill-worst-company-in-the...
| nitrogen wrote:
| Fair warning: the site has a translucent overlay that takes up
| half the screen on mobile.
|
| Can anyone summarize?
| carapace wrote:
| FWIW they also have a PDF: https://www.mightyearth.org/wp-
| content/uploads/Mighty-Earth-...
|
| Or just check https://en.wikipedia.org/wiki/Cargill#Criticism
| slater wrote:
| Here ya go: https://archive.vn/Zfw4P
| [deleted]
| zer0gravity wrote:
| Open-source is eating the world and, in some sense, the other way
| around too.
| wpietri wrote:
| I think it's hilarious that "blockchain-like" is how people are
| climbing off the hype train. I'm glad they're trying to find an
| exit, though, and I hope that lets software be blockchain-unlike
| enough that these systems aren't too weighed down with
| unnecessary constraints and costs.
|
| For those unfamiliar, people have been trying to solve supply-
| chain communication issues since the 1970s:
| https://en.wikipedia.org/wiki/Electronic_data_interchange
|
| The hard part is not technology. It's getting a zillion players
| to agree on how to use a technology together. To the extend that
| "blockchain [jazz hands]" ever mattered here, it was only the
| chance that the tidal wave of hype might sweep everybody in the
| same direction.
| fbrusch wrote:
| Couldn't blockchains offer some new tools to tackle the
| problem? Imagine for instance wanting to create some incentives
| by distributing the value of correctly tracking an item to the
| actors of the supply chain, with some rule like "once the item
| is sold, part of the revenue gets distributed to all the actors
| that contributed to the tracking". Wouldn't smart contracts
| render this simpler to implement, since code is visible by all
| actors and guaranteed to be executed?
| wpietri wrote:
| I doubt it. The only place where I see blockchains in
| significant practical use is in very low-trust cases. But
| supply-chain relationships already involve a fair bit of
| trust. Cryptocurrencies are also attempts to solve problems
| of financial interaction, but these people already have
| financial relationships.
|
| Moreover, I think one of the big problems with "blockchain
| [jazz hands]" is what you're doing here: a solution looking
| for a problem. The right way to build something is to start
| with actual problems actual people have and then find the
| most economically efficient technology that best fits the
| solution. When approached from that perspective, I still
| haven't heard of a case where a blockchain turned out to be
| the right answer.
| coderintherye wrote:
| William, while I agree the problem at hand is mainly an
| organizational one, you ignore that even with a trusted
| environment you still need safeguards for internal fraud. A
| distributed ledger can ensure that protection and easily
| verifiable audits. The distributed ledger solves this real
| problem, but with the caveat that as you noted that is a
| fairly small part of the overall picture.
| qeternity wrote:
| I got my start trading for one of the big commodity shops.
| The problem isn't incentive. Markets create natural
| incentives. The problem is authority. Who decides what's
| right? Who decides what constitutes "solved"?
|
| Blockchain or smart contracts have no way to solve this
| without abandoning the decentralized and permissionless
| aspects, at which point you're giving up loads of efficiency
| for none of the benefits.
|
| This is the problem that every large non speculation based
| blockchain problem has encountered: any system will be
| reduced to its weakest link. Any problem that requires
| crossing off chain into the real world will necessarily lose
| many of any benefits blockchain can provide.
|
| Blockchain really only solves a few specific problems in a
| few specific domains. There's a reason that a decade on, all
| we've managed to build are massive casinos that can't be shut
| down by authorities
| snarf21 wrote:
| The issue isn't one of trust in the general sense. Blockchain
| would "solve" the issue of transparency about when and who
| signed for what shipment where and when. The problem that
| can't be solved is that you have to completely trust that the
| blockchain reflects actually physical reality. A blockchain
| signature doesn't mean it is actually where it says it is.
| Even if you have some digital "fob" device, how do you know
| that it is on the right pallet of good. A digital signature
| can't prove anything in the real world. Blockchain is only
| useful in the pyramid scheme world of coins.
| toomuchtodo wrote:
| That's digital signatures and business logic with more work
| and cost.
| binarymax wrote:
| Please tell me what a blockchain offers here that isn't
| solved by several database tables and some business logic?
| thinkmassive wrote:
| private blockchain = federated database
| icegreentea2 wrote:
| I think the smart contract part of blockchain doesn't offer
| much value.
|
| But I think the core value proposition of blockchain to
| supply-chain like situations is to solve the problem of
| "who's version of the database do we trust", without
| needing to resort to escrow or other 3rd parties. It won't
| completely solve the problems of parties being in
| disagreement - lawyers will still be needed, but it might
| address a subset of problems.
| damnyou wrote:
| Smart contracts can help with things like escrows. You
| can automate the happy path and include humans in the
| loop if (when) something goes wrong.
| wpietri wrote:
| "Whose records do we trust" is a problem that's thousands
| of years old. [1] In practice, the answer is "we both
| keep records and compare when there's a problem". It's
| not clear to me that having a single shared database
| solves more problems than it creates.
|
| [1] https://www.bbc.com/news/business-39870485
| damnyou wrote:
| "we both keep records and compare when there's a problem"
| is literally exactly what blockchain consensus is an
| algorithmic version of.
| notahacker wrote:
| Any single centralised database performs that function
| though, since supply chains are emphatically _not_
| trustless and there 's no more guarantee updates to a
| blockchain corresponds to actual changes to the physical
| goods. "What if the party that manages the database
| reverts data entered?" is really quite low on the list of
| risks involved in transferring goods of value between
| multiple independent parties, ensuring all contractual
| and legal requirements have been met and paying
| separately, and anyone given read access to a centralised
| database can identify edits anyway.
| damnyou wrote:
| While it is true that blockchains themselves cannot
| guarantee that they're synchronized with the physical
| world, they provide an irrevocable digital trail that can
| be used to punish bad actors, one that is relatively
| immune to tampering. A lot of the world operates this way
| --simply signing something under penalty of perjury does
| not guarantee that it is true, but it can be taken to
| court if it is later found that you're lying.
|
| A blockchain ( _not_ proof-of-work, but permissioned
| /BFT-based) is pretty clearly the optimal way to have an
| irrevocable digital trail.
| notahacker wrote:
| Sure, I'm not disputing that they can fulfil a role, I'm
| noting that [i] they're not remotely close to being a
| solution to the sort of problems parties use escrow for (
| _except_ where the goods are digital to the extent
| fulfilment can be encoded into some sort of smart
| contract) and [ii] a distributed ledger only has _value_
| over and above a non-distributed one if other parties
| worry about the centralised database manager tampering
| with records [without leaving obvious evidence behind],
| which has got to be so far down the list of potential
| issues with most supply chains (even with respect to
| record keeping) it 's barely a consideration. Another
| vendor's good old fashioned cloud datastore might be
| equally suitable as far as parties not being able to
| update records without leaving an audit trail goes, and
| quite possibly with a shinier front end and easier to use
| API.
| damnyou wrote:
| > they're not remotely close to being a solution to the
| sort of problems parties use escrow for
|
| But you _can_ encode fulfilment into a smart contract for
| physical goods, assuming that those physical goods have
| some digital representation on-chain. Discrepancies
| between the chain and the real world continue to be
| resolved through the court systems in various
| jurisdictions, but on-chain activity is just strong
| evidence that any court can rely on.
|
| > a distributed ledger only has value over and above a
| non-distributed one if other parties worry about the
| centralised database manager tampering with records
|
| An alternative viewpoint is that a centralized database
| manager can be seen as a potential risk. One of the
| general ways we progress in society is when we reduce
| sources of risk, and a permissioned blockchain where you
| need 2/3rds of a cabal to collude is a pretty clear
| reduction of risk compared to a centralized DB. (I mean,
| how would you keep track of whether a central DB has been
| tampered with? You'd probably maintain your own copy,
| reconcile the two periodically, and flag discrepancies if
| and when they happen. That's exactly what a blockchain
| is.)
|
| To be clear, I'm pretty skeptical about blockchains in
| general, but this seems like a very compelling use case.
| notahacker wrote:
| > But you can encode fulfilment into a smart contract for
| physical goods, assuming that those physical goods have
| some digital representation on-chain.
|
| But why would I want to? Unlike a smart contract for some
| verifiable code-based outcome it doesn't offer any
| guarantees I get paid, which I still rely on the courts
| for, it just adds complexity and unfamiliar risk.
|
| > An alternative viewpoint is that a centralized database
| manager can be seen as a potential risk
|
| Sure, in theory it can be. But relative to all the other
| potential supply chain risks, the ERP cloud vendor
| colluding with a part of the supply chain to remove
| records from or silently update a datastore is pretty
| near the bottom of the list in terms of likelihood,
| expected cost and chances of it not being glaringly
| obvious to other parties and used as evidence of bad
| faith on their part in court.
|
| To be clear, I'm not saying blockchain can't be used as a
| datastore, I'm saying that overall its about as useful
| for mitigating supply chain risk as insurance against
| your spouse committing identity fraud is for mitigating
| potential problems with marriage.
| damnyou wrote:
| Well, the assumption is that unfamiliarity risk goes down
| as people get more familiar with the technology. There's
| certainly some added complexity but a blockchain is not
| that complex, it's just a git repo with some added
| functionality to repel hostile actors.
| ptx wrote:
| Doesn't a permissioned blockchain require a trusted
| central authority to manage the permissions? How is it
| better than having that central authority manage the
| database?
| damnyou wrote:
| You have, say, 50 entities that are part of the cabal,
| not all of whose interests are aligned (this is the
| important bit, you want a diversity of interests), and
| you need a 2/3 vote to add a new one.
| eli wrote:
| Is that a goal that anyone involved actually wants to
| implement? Does the code being visible really add any value?
| The problem isn't in executing the contract among people who
| agreed to it.
| [deleted]
| skywhopper wrote:
| Reading the article, it's clear there is nothing resembling
| actual blockchain/cryptocurrency technology involved. The
| engineers have built something with the features Cargill thinks
| their supply chain needs, and the marketers (or the savvy product
| managers) are just using "blockchain-like" as a descriptor and
| other crypto-adjacent buzzwords to generate interest and
| attention. It's probably the inevitable endpoint of all the years
| of blockchain hype from people who didn't understand the system
| to begin with---keep using and evolving the buzzwords and apply
| them to entirely different, old-fashioned, boring tech that
| actually addresses business needs.
| mikewarot wrote:
| What I would like to know is how did this come to exist in the
| first place? I realized Cargill is HUGE, but an open source
| system that supports private sub-networks?!?!?
| wpietri wrote:
| If I were a betting person, I'd guess that somebody with social
| connections to Cargill (e.g., an ambitious executive) took
| advantage of the blockchain hype cycle to sell a pilot project
| to credulous executives. The copyright says "2018-2020", which
| fits well with the cycle:
| https://trends.google.com/trends/explore?date=all&geo=US&q=b...
|
| I presume it's getting open-sourced now because they've given
| up on the idea of closed-source domination of the industry, and
| this is the hail mary attempt on the part of the technologists
| to save the project, or at least to have something good on
| their resumes by the time the project funding runs out.
| [deleted]
| acrooks wrote:
| Commodity firms and other businesses in the supply chain space
| (shipping, logistics) have a long history of trying to build
| platforms to simplify global trade. While a great goal, over and
| over again these initiatives have failed because of immense
| inertia in the industries and because of the fact that every
| single counter-party involved in a transaction must be on the
| platform for it to work.
|
| For a merchant to use Shopify, connected to Stripe, connected to
| Visa, working with me, it's relatively "easy". Not many people
| involved in the process and some of them (me) don't have any
| power to control how the flow works.
|
| When Cargill ships a 100,000 MT parcel of grain to be processed,
| there are SO many people and organisations that touch the
| commodity in some form. From inspection companies like SGS, to
| rail lines, to customs authorities, to port representatives, to
| ocean transportation, to banks....the list goes on. And
| historically the vision has been an "all or nothing" style of
| platform.
|
| One day we will figure out the solution to this problem, but not
| anytime soon and probably not with Splinter. Four of the world's
| five largest grain companies, three of the world's five largest
| iron ore companies, and many more use the product that I work on
| (www.SEDNA.com) to manage their global supply chains, and their
| workflows remain to be very email-based and driven by traditional
| ERPs.
|
| You see this in action with businesses like Flexport who started
| with a very formidable vision to build a platform for third-party
| logistics, and ultimately had to pivot to become a very digital
| freight forwarder after being trapped by the traditions and slow-
| moving nature of the industry.
|
| In these organisations there is incredible buzz and thought
| around digital transformation, but many of these companies are
| also only recently beginning to trust cloud software. So although
| there is a big desire to innovate and operate on the cutting
| edge, so many primitives and so much of the day-to-day process
| keeps them lagging behind.
| LaundroMat wrote:
| One innovation that really got adopted throughout the supply
| chain is the container.
|
| Agreed that it's only part of the supply chain compared to what
| you describe, but it was a major change that affected a very
| large amount of processes and businesses.
|
| The scale of things such as worldwide supply chains makes you
| wonder whether competition is really the right catalyst for
| efficiency. Cooperation and the setting of standards seems to
| be a better answer, but of course this leads to a whole lot of
| different issues.
| throw0101a wrote:
| > _One innovation that really got adopted throughout the
| supply chain is the container._
|
| If anyone is interested in learning the history of this, a
| good book ( _2e_ : ISBN 978-0-691-17081-7):
|
| * https://en.wikipedia.org/wiki/The_Box_(Levinson_book)
|
| It really took off during/after the Vietnam War as the
| Pentagon saw its benefits in efficiency and not having to use
| Old School longshoreman and switching to cranes.
| noahl wrote:
| Interestingly, there was an ancient Greek / Roman
| equivalent: amphora (pottery vases) with bumps that fit
| into standard cargo racks in ships.
|
| The first picture in the Wikipedia article is what I mean:
| https://en.m.wikipedia.org/wiki/Amphora .
| MagicWishMonkey wrote:
| It's amazing that something that seems as obvious and
| simple as "shipping stuff in a box" is a relatively recent
| innovation.
|
| Makes me wonder what seemingly obvious thing we're not
| aware of right now that will be commonplace 50 years from
| now.
| Spooky23 wrote:
| Think about railroads and even early highways. It's hard
| to standardize before you have a problem.
|
| Containers have big downsides too... but technology
| allowed costs to be vaporized with containers.
|
| The other big thing is that containers appeared in the US
| as the railroads entered their death spirals. You can
| build a dock anywhere and have trucks show up from 100
| companies quickly compared to the negotiation required to
| live railroads. Think about how quickly the NYC maritime
| business died and moved to New Jersey... that's a market
| that represented ~10-15% of the US population at that
| time.
| BurningFrog wrote:
| There were always boxes, but I think the real game
| changer was _standardizing_ the size and other properties
| of the box, across the planet.
| flower-giraffe wrote:
| Absolutely - standardisation is the path to ubiquity.
| From the screw thread to the accidental standard (ISA) of
| the IBM PC.
|
| It removes many of the barriers to competition and
| reduces the risk of large players creating monopolies.
|
| I think it's fair to say that much of what we see in tech
| is deliberately engineered to avoid standardisation in
| order to protect competitive advantage.
|
| Wired did an interesting article on standardisation years
| ago.
|
| https://www.google.co.uk/amp/s/www.wired.com/2002/01/stan
| dar...
| nitrogen wrote:
| Eventually we will figure out better protocols for data
| federation, replacing centralization of digital
| infrastructure with standardization.
| menzoic wrote:
| It took collaboration to integrate the containers but not
| necessarily to create it. Creating requires risking resources
| which is incentivized by the potential monetary gain. Without
| that potential, it's hard to imagine competitors risking
| their resources. Another point about collaboration in this
| case is that it only happened because all parties benefited
| more. If you don't adopt new things that optimize operations
| then you'll be left behind by your competitors who are
| operating more efficiently and have wider support for the
| customers everyone is competing for.
| mschuster91 wrote:
| The container was adopted very fast and very thoroughly
| throughout worldwide supply chains because it was many, many
| orders of magnitude better - and allowed a _massive_
| reduction in staff.
|
| No proposal for better IT integration in freight comes even
| close to that level of saving, mostly because the existing
| chaos is "good enough" and the executives are very, very old
| and very conservative compared to "digital natives".
| Ericson2314 wrote:
| And sticking it to the once-fearsome longshormen's union is
| much more appealing to sticking to yourself and your
| manager retainers.
| Closi wrote:
| A closer innovation for supply chain might be the concept of
| an ASN (although anyone who works in logistics knows how
| disparate different supplier portals can be...)
| vmception wrote:
| > there are SO many people and organisations that touch the
| commodity in some form
|
| and 99.9% of those people are a joke and don't even realize it.
| commodities traders are the most gullible lot I've ever
| encountered, chasing a pot of gold at the end of a rainbow.
| they're so dumb as they cannot tell reality from fiction.
| craftinator wrote:
| > they're so dumb as they cannot tell reality from fiction
|
| Ya know, here in the US we just found out that nearly have of
| our population and our last president have this problem.
| Maybe they should move into trading commodities?
| vmception wrote:
| the answer is yes its the same current of people and it is
| global
|
| Think of it like real estate agents, but without even the
| bare minimum of the license. You have people with no
| marketable skills, no formal education, no success at
| anything else all chasing commissions. Its going to be a
| circus.
| jeffreyrogers wrote:
| I don't think you know much about how commodities are traded.
| Can you even name the main players?
| robk wrote:
| Explain more?
| vmception wrote:
| There is a shadow economy full of people chasing fake
| commodity trades. There's nothing more to explain.
| plaidfuji wrote:
| > their workflows remain to be very email-based and driven by
| traditional ERPs
|
| This really is the crux of the issue. It comes down to "your
| ERP has some information I want in my ERP" - followed by twenty
| emails, redirects to find the person who actually understands
| the schema of the ERP on each end, mapping the fields, and
| finally sending the info.
|
| What's missing is not some omniscient decentralized master
| system, but a standard framework to rapidly conduct data
| negotiations between private parties and systems. Each party
| needs a public-facing searchable data catalog of some kind so
| requests can be made precisely the first time, and so each
| party understands what they're agreeing to.
| openthc wrote:
| This happens in the cannabis game. There are 120+ software
| vendors, so to make it easy humans email each other links,
| those links also have pointers to the data (JSON), so that
| the receving end can just paste it into their end.
|
| But, wow! Is it hard to get your competitors to adopt an open
| protocol. Whole bunch of NIH syndrome. And each player can
| sit on the sidelines, or invent their own "protocol" and not
| adopt another (que that XKCD about 14+ standards).
|
| Converstaions: A: our clients want to work together, so our
| softwares should work together. B: Yea, well, how many
| clients do you have? A: Well how many do you have? B: Use my
| protocol, we'll build a spec. A: here's our protocol with
| public spec & moderate adoption. B: Well, we didn't get to
| have input so we don't like it, you're clearly not a team
| player. A: It's on Github! I'm literally inviting you to
| participate right now!? B: ...
|
| It's very hard to build open, distributed, federated systems
| when all the other parties in the game are more interested in
| building up their own walled garden.
| aaron_m04 wrote:
| > What's missing is not some omniscient decentralized master
| system, but a standard framework to rapidly conduct data
| negotiations between private parties and systems.
|
| What is the difference? You seem to be recommending a
| protocol (maybe with some level of human involvement) between
| two centralized systems. OK now that sounds more like
| federation than decentralization, but still, there's not much
| of a distinction.
| a3n wrote:
| Truck driver. I just picked up a trailer of toilet paper in
| Portland, bound for Ontario CA.
|
| The guard handling the paperwork asked me "Are you able to sign
| online?"
|
| I desperately tried to come up with a snappy "yep," it sounded
| like such a good idea. But I finally had to say "I'm not sure
| what you mean."
|
| He handled it, gave me my bill of lading, and away I went with
| toilet paper in tow and paperwork in hand. Because it's still
| not finished until the paperwork is done.
| azinman2 wrote:
| I'm curious about this intersection of truck driver and HN:
| not the typical demographics. What got you into either
| trucking or tech (not sure which was first)?
| jhayward wrote:
| There are a lot of people who left white-collar jobs for
| trucking; engineers especially. Something about wanting to
| be more or less your own boss, control your own schedule,
| and not be in an office is appealing.
|
| So your stereotype for "trucker" has to be resilient to the
| occasional former nuclear physicist or mathematician
| showing up.
| a3n wrote:
| I used to be in software, which is how I found HN. Then I
| rage-quit my last in-career job.
|
| I was a B-player, and past my fresh date. I stumbled around
| a bit, and wound up here.
|
| I like it. I haven't been in a meeting in three years, and
| my commute is three feet. Right now I'm in California on
| I-5, looking at Mt Shasta floating above the clouds.
|
| I get paid to look out the window.
| Spooky23 wrote:
| I think some of these things also start to address internal
| controls issues.
|
| The Cargill branch in my area lost at least $3M to embezzlement
| by an accountant who just paid phony or stretched invoices for
| years, which gives you an idea of the risks associated with
| paper and excel processes combined with lean staffing and lack
| of controls.
| pm90 wrote:
| Yeah, but this person will probably get prosecuted and fired;
| corporate attorneys are probably already on hand and expected
| to fight these sorts of cases. It's unlikely that this is too
| common of a situation.
|
| Compare that to fully digitizing. Will cost many more
| millions in procurement and training.
|
| There are advantages to digitizing. But until they're really
| transformative, conservative industries won't budge. And they
| won't budge until the benefits of going fully digital become
| so large that a competitor/startup comes along and realizes
| these benefits and kicks their asses at which point they too
| need to transform or die.
| nerdbaggy wrote:
| Hopefully it will fix their child slavery issue in their/others
| chocolate industry - https://www.slavefreechocolate.org/news
| anarchop wrote:
| Of course one would hope this platform single handedly leads to
| major advancements on industrialisation, permanently
| eradicating child labour and slavery in all industries. One
| would also hope that simply not buying chocolate sourced from
| farms that employ child labourers that should be in school (as
| opposed to older children that don't need to be at school,
| which according to the data I can find actually represents the
| vast majority of child labourers in the cocoa industry) would
| also solve the issue. My fear is however that it's not that
| simple, and we could even make things worse. For example, child
| labour numbers have increased in recent years, haven't been
| able to find percentages over time so cannot comment on that.
| One could hardly say that "ethical sourcing" and marketing has
| proven that it's reduced child labour given this increase.
| UShouldBWorking wrote:
| Its not a bug, it's a feature of a messy supply chain.
___________________________________________________________________
(page generated 2021-01-23 23:02 UTC)