IOTA for Inventory Management
IOTA is being considered for our next-generation ledger of things.
Paper is for targets.
Blockchain for ledger? Sounds nice but there are some show stopping issues with blockchain technologies that exist today. Aside from the scaling issues of blockchain, there are transaction fees associated with every coin implementation, especially smart contract currencies.
In the world of mission critical record keeping for firearm manufacturers, law enforcement, public safety, and military organizations; a fully decentralized ledger is our 2018 mission at APB360, using IOTA and the Tangle.
“IOTA is a futuristic protocol in distributed ledger technology. It is more than just a cryptocurrency. Even as a cryptocurrency, with it’s zero transaction fee, unlimited scalability, ability for nano transactions and quantum resistance, IOTA overcomes all the limitations of traditional cryptocurrencies like Bitcoin, Ethereum and Ripple. It works on a technology called DAG (Direct Acyclic Graph) and the IOTA implementation of DAG is called ‘Tangle’. IOTA has the potential to disrupt the entire financial, database management systems of the world by enabling micro/nano transactions in the IoT (Internet of Things) , as a facilitator in the IDoT (Identity of Things) , as a replacement to money in human to human transactions, in secure messaging, data storage, data security and validation.” –Medium Article
If you are interested in our intended architecture and would like to participate, please continue on.
APB360 currently manages millions of assets and custody records. For every asset, it is common in manufacturing to have multiple acquisitions and dispositions. The current APB360 implementation of the Acquisition and Disposition (A&D) ledger is a highly available, geographically clustered, distributed database with heavy redundancies. This results in many millions of rows across hundreds of normalized schemas. For every asset, there is likely 4 to 6 different A&D records.
For every asset, depending on if we are referring to the law enforcement version of the ledger engine, or the Federal Firearm Licensed (FFL) manufacturer or distributor version, an acquisition record must exist at minimum for every asset. This record is supplemented with a variety of useful meta, but most importantly, the serial number, manufacturer of record (Make), the model, the type, caliber, the source of acquisition (where from), date, active storage location, and potentially a manufactured date and licensing information. This is the start of the chain of custody, and FFL users are legally liable to maintain these records in an immutable fashion. Failure to comply is costly, federal entities can close your business and take your freedom away.
The nature of the Tangle provides the “unchanging over time or unable to be changed” requirement for ledger purposes. In addition, the IOTA implementation is a fee-less network of many nodes, all providing consensus for transactions. Now that we have that covered, let’s talk about implementation.
For every asset, there is a seed. For every acquisition source and destination, there are also seeds. The APB360 database will have to track and manage these private seeds in the millions.
IOTA has total fixed supply of 2,779,530,283,277,761 units with zero inflation. If we utilize one IOTA for every asset and custody source, we will barely deplete the money supply. A million IOTA’s (Mi) is currently trading around $3.70 (12/29/17).
Here is a PoC scenario to work with (a more complicated than necessary example):
- A Glock 17 9mm Luger, serial number 123, is purchased from Company A and stored in an active location (safe) on premises.
- An armorer (employee) extracts the Glock from the safe (serial# 123) to inspect and prepare for employee assignment
- An employee is assigned the firearm for a qualification shoot and ultimately for duty
- Time passes, and the firearm needs preventative maintenance. The employee returns the firearm to the armory employee
- The armory employee accepts the firearm and places it in the safe, it will be several days before the firearm can be inspected.
- The armorer extracts the firearm, serial 123, from the safe to do work.
- After the work is completed, the armorer returns the firearm to the safe.
- The employee is contacted to return to the armory to get the firearm. The armorer then extracts the firearm from the safe.
- Finally, the armorer assigns the firearm back to the employee for duty.
This represents 9 records in the ledger. Note how the firearm is treated in this example as a constant flow from Acquistion to Disposition. As it enters an individuals hands or enters a physical storage location, the event must be recorded in the ledger. Using RFID and NFC, or 2D barcodes, the bureaucracy of all this is pretty much eliminated. But there is one particular thing to note, the high fidelity of custody records. If the firearm location status is “On Premises”, it cannot be Acquired again. This is a constant opportunity to correct the real chain of custody.
For example, the employee returns the firearm to the armorer, but the firearm ledger shows that it is still on premises. How can this be? The armorer didn’t perform the correct operating procedure to assign the firearm back to the employee, and APB360 makes it clear to them. Enter IOTA.
- An asset is acquired from a vendor. Every asset is born with 1i.
- A SEED is created for that asset and a wallet is attached to the Tangle.
- APB360 transfers 1i to the asset wallet.
- The location for storage is given a SEED, and a wallet is made and Tangle attached. The asset is stored in a safe, and the safe’s wallet receives 1i
- An asset is inspected.
- A SEED is created for the armorer because the armorer is going to take custody of that asset and a wallet is made and attached to the Tangle.
- The safe wallet transfers 1i to the armorer.
- We know the asset is in employee custody (off-premises essentially) because the asset’s seed/wallet has zero balance and a historical transaction to the armorer (trace)
- The armorer completes the inspection and returns the asset to the safe.
- The armorer’s wallet transfers 1i to the safe’s wallet
- An employee is coming to the armory for the firearm, the armorer removes the gun from the safe.
- The safe’s wallet transfers 1i to the armorer’s wallet
- The employee arrives to acquire the firearm.
- The armorer’s wallet transfer 1i to the employee.
You probably get the idea. The wallet balance servers as the fidelity checkpoint. If the wallet has no IOTA, it shouldn’t have the asset. The big question is:
- Will we make a seed/wallet for every transaction, and when they are zero, the chain of custody should have a continuation?,
- Will we allow for employees and or locations to have one wallet with several IOTA, and depend on APB360 to decipher what should be with them or not?,
- Or should we have one wallet, transfer IOTA to itself, and simply store the transaction hash in a database to correlate to something?
- I’m sure there are more, which is the point of writing this blog post.
In case #2, the safe or designated storage location could have thousands of IOTA, each IOTA representing an asset. In addition, the armorer could have several IOTA. Also, the employee as well could have several dozen IOTA. Often, LE employees will have several firearms, OC spray, tasers, taser cartridges, body armor, holsters, belts, helmets, and more. Each asset would have a seed identification, and chain of custody would be in the Tangle.
Tangle communication would exist using micro-service architecture talking to our own nodes, asynchronously, to avoid being a bottle neck during the work flow. Like a batch job. However, checking an asset or employee wallet would be real-time while consulting the APB360 engine.
Feasible? We invite you to communicate with our team on Slack on the #iotatangle. Look for @Adam Lyons or the APB360 channel on iotatangle’s slack (#apb360)!
Comment below with your IOTA address or connect direct, quality feedback will receive IOTA!
Comments (2)
Great post and thoughts I must say.
Obviously there is more to the process flow than you have managed to put in words here. Also, as always with new ideas, there will exist some blind spots that can only be exposed by implementing the idea and testing it out in the field a.k.a alpha version.
To begin this conversation, I will give my answer/opinion to the questions you have raised and we can explore and exchange ideas further on Slack (@raresight)
Q: Will we make a seed/wallet for every transaction, and when they are zero, the chain of custody should have a continuation?
A: I don’t think this will make a good design. It sounds like creating a new bank account for every transaction you make?
Q: Will we allow for employees and or locations to have one wallet with several IOTA, and depend on APB360 to decipher what should be with them or not?
A: This sounds like a better idea, here is my take:
These are the agents I have identified:
i) Manufacturer, ii)Vendor, iii)The Asset, iv)Storage Location(I am assuming this is run by a registered operator), v) Armorer, and vi)Employee.
I think everyone of these agents can have there own wallets. Because they have their own wallet, this equips them to make and receive “transactions”.
1. So an asset is born by the manufacturer. The manufacturer initiates a zero transaction to asset’s wallets
2. A vendor comes to acquire the asset, if the payment medium is IOTA, the vendor will initiate a non-zero (asset amount in IOTA) transaction to manufacturer. The manufacturer in return initiates a bundle(can contain more than one transaction – in this case two zero transactions. one to the vendor wallet and the other to the asset’s wallet).
3. A Storage Location(SL) acquires asset from vendor, the SL makes a non-zero transaction to vendor and vendor makes a similar bundle of transactions as above(two zero transaction in bundle – one to the SL wallet and the other to the asset’s wallet)
4. Armorer picks asset from SL for inspection, again bundle of transactions is made by SL(two zero transactions – one to armorer and the other to asset)
5. Armorer returns asset, then the armorer makes the bundle this time (two zero transactions – one to SL and one to asset wallet)
6. Same goes for the employee picking and returning an asset.
Let’s look at some other questions this design answers:
1. Agents in this transactions are not required to have iota values in their wallets except for agents making non-zero transactions. In fact, the asset will never have an iota value in its wallet.
2. All transactions linked to an asset’s wallet will tell us right away the true and entire history of that asset.
Now to the question of running your own node. Yes, I believe it is the right thing to do here. run your own fullnode.
Things to keep in mind:
1. You must have high performing and reliable neighbours.
2. You node must also be high performing and reliable as no one running a reliable node will add you as neighbour if your node is not.
I hope you find this helpful.
Cheers!
I’m going to focus on this part for the moment:
An employee, armorer, vendor and location are all really the same thing, they are links in the chain of custody. The asset (inclusive of manufacturer and properties like model and type) is the item being transferred, where the premises of the asset changes from wallet to wallet. The asset is the coin basically, what would be interesting is if there could be a way to make every coin distinct somehow. Like a signature to the coin itself. Of the billions of IOTA in supply, wouldn’t it be cool to have a distinctly identifiable coin in the Tangle?
Using the Tag feature on every transfer could be a method to achieve something similar to coin tagging. Encoding some message in the coin transfer for each asset. The message could be something that only APB would be able to decode, thus providing some privacy/security. Looking at the anatomy of a transaction, there is a 27 trytes capacity in the tag, but the signatureMessageFragment has 2187 trytes, far more capacity. It is unclear though how or which opportunity there would be to encode data in the signatureMessageFragment.