Europe has the largest global invoice factoring market for over 1.6BEuro. The purpose of a factoring market is to address delay in payments of commercial invoices by buyers of good and services: sellers bring their still-to-be-paid invoices to nancial organizations (factors) which provides an advance payment. The market further growth is hampered by a number of security issues such as the impossibility of factors to check whether an invoice has been already factored (double pledging). A global organization collecting all factored invoices could be a solution but all stakeholders (banks, factors, etc.) have various reasons to not wanting to share such data. In this scenario a distributed, blockchain-based implementation is the only way forward, We describe the security requirements and all key operations for a secure, fully distributed Invoice Factoring Market, hereafter referred to as simply the `Market'. Our distributed, asynchronous protocol simulates the centralized functionality under the assumption of the availability of a distributed ledger. We consider security with abort (in absence of honest majority).
When a seller issues a commercial invoice to a buyer, the latter may have several months to
pay it (from 30days to 120days). In the meanwhile, the seller has to pay its own suppliers,
its workers and other operational costs. To cope with such payments delays by buyers, the
seller brings the invoice to a factor (which might be a bank or another specialized nancial
organization) and try to obtain an advance payment by pledging the invoice as a collateral.
The factor grants a payment, typically a fraction of the amount on the invoice, subject to a
risk assessment involving the credit worthiness of both buyer and seller [
Europe has the world largest factoring market and the volume of factored invoices has increased to 1,6BEuro in 2017 from less than a billion in 2010. This increase can partially be explained by several factors: economic growth and therefore a larger number of invoices, increased ability for factors to estimate risk, lower cost of capital and entrance of new actors
in the market. Yet, most small companies are poorly served by this nancial market which is
instead recognized to have the potential to address the liquidity needs of small companies [
Two critical features of an invoice market are extremely di cult to evaluate for factors: authenticated identities of parties involved (seller and buyer) and whether or not an invoice has already been factored. As a result, factors can be victim of frauds by sellers that factor non-existent invoices or factor an invoice to multiple factors (double pledging ). At the same time, buyers might be contacted by fraudulent factors that claims to have factored an invoice of a legitimate seller and demand payments for such invoices. Even in absence of frauds, paying the invoice to wrong organization creates a number of issues.
A quick solution would have been a centralized system where all invoices could be stored and checked by interested parties. Yet, in spite of the existence of the factoring market for centuries, no such entities emerged1.
The main reason for such absence is the quest for con dentiality. For di erent reasons,
buyers, factors, and sellers have no interest of sharing information on past invoices as it can be
used against them. For example, a buyer knowing that a seller routinely factor its invoices may
worsen the payment terms \as you will receive the money anyhow, right?" Another example: a
factor, knowing that there is an ongoing factoring relationship on the invoices between a seller
and a credit worthy buyer, may come forward to the seller o ering better factoring terms than
its current factor. Such access control relations cannot be managed by traditional role based
access control [
To address such challenges, we propose an ideal reactive functionality where all the parties send their private inputs to a trusted third party, which manages the market. Then we show how this information can be captured by using a distributed ledger with commitments that protects the integrity of the data and the con dentiality of all interested parties.
Our goal is to mimic as much as possible the actual current process and minimize the role of cryptography and the blockchain ledger to boost the possibility of adoption by existing automated systems for invoice managements at sellers, buyers and factors. Our security protocol is hybrid. We make use of a permissioned, distributed ledger, where authenticated peers maintain the consensus for a distributed ledger which stores all commitments of all secret values while the secret values are only stored locally by the peer who owns the data.
A key feature of our protocol is that access to the data must go through the data owner, i.e. a peer who doesn't have the desired data must request the data from the peer who owns it. The data, if accessible by the requesting peer, will be sent through a private secure channel between the two peers (we also called this an out-of-band channel). The commitments in the distributed database are used only to verify the received data (and possibly for solving disputes). 2
Advancing payment on invoices (factoring) has long tradition in the banking and nancial sector
[
1In contrast centralized entities dealing with transactions such as stock, commodities, and futures exist [
Intuitively, the entire relationship is essentially based on a \story" (the invoice) by the Seller who told the Factor that the Buyer owed him something. The invoice reports at least • who are the Seller and the Buyer (typically identi ed by the VAT number), • the Seller's credit (the amount) and the deadline when the payment is due, • the payment's bank (where the Buyer would send the money).
From the perspective of the Factor, it has document in its hand which, if not false, certi es the Seller's credit. Eventually a bank of the Buyer will transfer this amount into the Invoice's bank account and this will happen because the Buyer said to its bank this story was actually true. However, from the perspective of the relationships we have no warranty whatsoever that the artifact supporting the story is actually true, not that the same story has not been told to several di erent people in the hope of extracting money from all.
Indeed, a seller can issue invoices as long as it wants. It might even be that the invoice is true in the Seller's head but if disputes arises on the debt by the Buyer, the Factor is anyway at zero. It might also be that the Buyer has paid somewhere else and would therefore refuse to pay. While this should be a bad practice, it happens, often by mistakes. For example if the Seller had previous relationship with the Buyer, the Buyer might have automatically used the previous bank account of the Seller without checking whether it has been changed in the meanwhile.
Factoring typically takes two forms: recourse factoring and factoring without recourse. The former is the most traditional form of factoring, essentially a loan o ered by the banking system in which the invoice is simply a speculative form of collateral. The latter is the most common type in Italy and on most advanced nancial markets. Reverse factoring is a nancial (usually exclusive) agreement mostly used by major industrial groups. Reverse factoring allows suppliers to be paid in a timely manner for a fee that is taken care of by the group (\champion"). In this case is the buyer itself that propose factoring to its small, weak, but strategic suppliers, as an instrument in business negotiations to obtain better terms of special products, better terms of delivery, and lower prices. By entering into the supply chain nancing mechanism, once the buyer has approved the invoice sent from the seller, the bank, in agreement with the buyer, will provide the seller with advance nancing. The buyer then pays the bank at the agreed time, with low interest rate due to its nancial strenght and low risk. In this way, small enterprises with bad credit scoring can receive instant payments because \champions can guarantee the bank that the money will be paid. Table1 summarize the di erences.
A common approach to factoring is a permanent relationship between a nancier and commercial enterprise which is also called Portfolio factoring in which all invoices from a seller are managed by the factor. In di erent markets this might have di erent embodiments and levels of automation.
For example in the Italian system a common way in which this is implemented is the form of RiBa (Ricevuta Bancaria - bill of exchange) which have a high level of automation. The Ri.Ba. as a credit and transfer instrument, is an order addressed by the Seller's bank to the Buyers' banks, requiring to pay a certain sum of money at a xed time following an interbank mechanism. The creditor's bank receives a set of orders for charges (typically corresponding to invoices) by the Seller. At due time, if the charge is authorized by each Buyer's Bank the money is transferred to the Seller's Bank. In the meanwhile the Seller's bank has already advanced the money of the orders to the Seller.
Remark 1. The advance payment of the invoice by the Factor may not be the entire amount mentioned in the invoice. This might happen depending on the level of risks and trust relationship between the Factor and the Seller (or the Buyer for non-recourse factoring). In the Italian system an advanced payment based on the invoices brought for a Ri.Ba. might be around
Recourse Factoring NonRecourse Factoring
80-100%.
Portfolio factoring makes it more cost-e cient to perform risk assessment, as it is close to impossible for the Seller to double pledge the invoices as they are all managed by its Factor. Yet, it limits the scope of potential customers to those willing to factor all invoices rather than a small selection. The ability to factor single invoices further increases the potential customer base but presents the concrete risk of double pledging.
A Blockchain system could bring several advantages: 1. the certainty of the uniqueness of the invoice, 2. the (potential) acknowledgement of the buyer, 3. the assurance of the advance of that invoice (i.e. it was anticipated by bank x on that day y).
Yet, there is also an important constraint that stems from the PSD2 European Directive. From the viewpoint of the participating banks and payment service providers the transaction must be open and all banks in the blockchain that have a business with the parties involved in the transaction must be potentially able to read it. In other words, access to the system must be determined in an automatic way by having a relationship with one of the parties of the invoice.
This challenge is a severe stumbling block that makes Role-Based Access Control [
Distributed Payment Network The most prominent example of a distributed payment network
is Bitcoin [
Blockchain-based FinTech Blockchain is widely adopted to implement distributed nancial
markets (see the survey [
Cryptographic Accumulators Cryptographic-based Invoice Factoring Market was introduced
as e-Invoice Factoring Problem which is obtainable through Strong Accumulators from
CollisionResistant Hashing [
Secure Multiparty Computation (MPC) Seminal feasibility results in the theory of MPC
established that any functionality is securely realizable via a distributed protocol in the
computational (resp. information-theoretic) setting, assuming honest minority (resp. majority) [
A typical evolution of the market includes i) Initialization of the market and Onboarding the participants; ii) Invoice Registration and Acknowledgement where a Seller and a Buyer agree on an invoice's data; iii) Invoice Factoring and Proposal Acknowledgement where a Seller and a Factor agree on and assign (when the Factor advances the agreed amount) an invoice factoring proposal, and nally iv) the Payment Registration and Invoice Settlement where the Buyer of an invoice pays and the corresponding assignee (either the Seller or a Factor - in the case where the invoice is factored) receives the payment.
For the actual transfers of money, all parties rely on a set of trusted parties called Payment
Service Providers 2 (PSPs) to route the money transfers. In typical embodiment. Those might
be banks or other organisations licensed to undertake payment services. In this respect one
can use traditional payment systems or novel cryptographic ones. See Massacci et al. [
For expository purposes, both in the ideal functionality FCIF's and in the protocol DIF's
description we allow an adversary to abort the computation after receiving its own intermediate
outputs. This avor of security is known as security with aborts [
• (join, buyer:B), add B = B [ fBg if B 2= B; • (join, seller:S), add S = S [ fSg if S 2= S; • (join, factor:F ), add F = F [ fF g if F 2= F; only by the PSPs. The market evolves in rounds, at round t = 0, the set of PSPs is known while the sellers, buyers and factors sets are empty. A party can onboard into the market by sending its (join, id) to FCIF.
Remark 3. PSPs are responsible to certify the correspondence to the protocol actions to some
actions in the real world. This corresponds to value creation into the system (See step 1 in
[
Buyers and Sellers could also be authenticated but they could still introduce fraud even if
authenticated. For example Buyer and Sellers could collude to create bogus invoices to extract
money from Factors and disappear. However, the presence of a strong eIDentity mechanisms
[
Invoice Registration and Acknowledgement. As illustrated in Fig. 2, to register an invoice into the FCIF: 1. The seller S rst composes a standardized invoice document D. The seller S must include some key information such as • H(D) a hash (e.g. SHA-1) of the readable invoice document, serves as a unique ID of an invoice; • S its own ID; and B the ID of the buyer; • v the value of the invoice; and e the expiration date of the invoice.
We also use the notation map(H; (s1; : : : ; sn)) to indicate the sequence (H(s1); : : : ; H (sn)). 2. The seller S then can register these information as an invoice I into FCIF as well as send the invoice document to the Buyer B. The buyer status of I is now set as I: B = sent. 3. The buyer B can now pickup the invoice I, cross-check it with the (out-of-band) received invoice document. If everything is correct, B will acknowledge the invoice I, i.e. the buyer status of I is now set as I: B = acked3. 4. The PSP P for handling payment related to this invoice is also speci ed during invoice registration since it has to be trusted by the Seller S.
Invoice Factoring and Proposal Acknowledgment. To factor an invoice I, three parties must participate: the seller S, the factor F and the PSP P (Fig. 3).
3The B could also abort the invoice registration by sending (abort). As we said, we omit the operation when Buyer dis-acknowledges an invoice for some reason. Invoice Registration Seller S composes the invoice document D (which is the readable form of the invoice), sends it out-of-band to the buyer B, and register the important information into the ideal functionality FCIF.
Upon receiving (send, H(D), S, B, v, e, P ) from S 2 S, the functionality FCIF will 1. create I and add I = I [ I; 2. set the status I:
(H(D); S; B; v; e; P ); 3. append I: B = sent into I; 4. send (send, S, H(I; map(H; I: ))) to all parties; 5. send (send, I, I: ) to I:sell and I:buy; 6. send (send, I, map(H; I: ), I:sell, I:val) to I:pay.
(I:hash; I:sell; I:buy; I:val; I:exp; I:pay) to Invoice Acknowledgement B upon receiving (send, I,I: ), cross-checks the invoice document D, and I, if they are consistent, sends (ack, H(I)) to FCIF, Upon receiving (ack; H(I)) from B 2 B, the ideal functionality FCIF will
2. update I: B = acked; 3. send (ack, B, H(I; map(H; I: ))) to all parties; 1. S and F must rst negotiate out-of-band the factoring term, i.e. the advanced amount
I:amount, which requires S to send the invoice document to the factor F . 2. The seller then can make an invoice proposal and register it into the ideal functionality, i.e. the factor is updated as I:f actor = F , the advanced amount is set as I:amount = v, and the factor status is now I: F = factor sent. 3. The factor will now be able to retrieve I from the ideal functionality FCIF and cross-checks the data for consistency, then either acknowledge (by sending ack factor, where the factor status will be changed to I: F = factored)4. 4. The PSP P will also be noti ed by the ideal functionality of the factoring situation for it to handle payment correctly. The PSP P is also responsible for updating the factor status to I: F = fpaid when it receives the correct payment from F .
Payment Registration and Invoice Settlement. The nal function of the ideal functionality is payment registration and invoice settlement (Fig. 4). As the round t advances, the invoice expiration noti cation is sent to all related parties (I:sell, I:buy, I:f actor and I:pay). 1. The payment registration starts with a payer (could be the buyer B when s/he pays the invoice or the factor F to advance the payment of the invoice) out-of-band comes to a PSP and make a payment with an I:hash as the reference. 2. The PSP checks if the paying amount is consistent with the payer and the expected amount, then routes the payment to the corresponding payee of the invoice: (a) If the payer is the buyer B, the amount must be at least I:val; and the payee will be the seller S (invoice is not factored) or factor F (if invoice was successfully factored); 4Similar to the invoice acknowledgment, we omit the operation where the Factor or the Seller withdraw the proposal. Invoice Proposal Registration Upon receiving (factor, F , I:amount, I:hash) from S 2
S the ideal functionality will Invoice Proposal Acknowledgement The Factor F upon receiving (factor, I), crosschecks the invoice document and I, if they are consistent, sends (ack factor, I) to
2. update I:f actor = F , I:amount = v, I: F = factor sent; 3. send (factor, S, H(I; map(H; I: ))) to all parties; 4. send (factor, I, I: ) to I:sell and I:f actor; 5. send (factor, I, map(H; I: ), I:f actor, I:amount) to I:pay; FCIF; Upon receiving (ack factor, I) from F 2 F:
2. update I: F = factored; 3. send (ack factor, F , H(I; map(H; I: ))) to all parties; 4. send (ack factor, I, I: ) to I:sell and I:f actor; 5. send (ack factor, I, map(H; I: ),I:f actor, I:amount) to I:pay;
Security of FCIF. The ideal functionality FCIF clearly captures the required data access control summarized in Table 2 for an invoice factoring market that integrates the trusted PSPs.
It also captures an important functionality for payment system. Every participant must be able to show that it has performed a due diligence process on the data that it has received from the ideal functionality.
On the side we provide the access control matrix for an invoice I IaPBn:FufdyawectrthhoeiBrchgaenins6=detrhPiIceS:bSPPueSylPlP,erFo6=SafcttIho:6=epraFIFya:scaetnlo6=ldr, F = I:factor. tor F 2 which is Walseoadlsioehreanvte fFroamc-. . . I:val I:factor but has received from the I:exp sIelfloerr athqeuiontfoe.rmAastioonneoncatnheiminmvoeidcie- I:amount ately see, only Dynamic ABAC can I: B smeattarpixp.ropriately this access control I: F
Permission I: B
I: F
Distributed Ledgers are ledgers maintained by a network of nodes. The most important property, e.g. for distributed payment networks, is consensus among the nodes, while still being fully decentralized. We use a distributed ledger, e.g. HyperLedger in PBFT mode (https://www.hyperledger.org) as a byzantine fault tolerant storage for each protocol step, i.e. each broadcast is replaced with a write into the distributed ledger. While we mention HyperLedger in our implementation, we can replace any sub-protocol with other protocols for the same task, without a ecting security.
Digital Signature Scheme is a tuple of polynomial time algorithms (KGen; Sig; Vf) that runs as follows. (sk; vk) KGen( ) takes as input the security parameter sk and verifying key vk. and returns a pair of signing key
Sig(sk; M ) takes as input the signing key sk and the message M , outputs a signature . f0; 1g = Vf(vk; M; ) takes as input the verifying key vk, the message M and the signature , return 1 upon successful signature veri cation and 0 otherwise.
Commitment Schemes. We rely on a non-interactive commitment scheme Com, with
domain f0; 1g . We typically write JvK := Com(v; rv) for a commitment to value v using
randomness rv 2 f0; 1g . To open a given commitment JvK, it su ces to reveal (v; rv), so that a
veri er can check that JvK = Com(v; rv). For the proof of security we need that JvK statistically
hides the committed value v, and after publishing JvK it is computationally infeasible to open
the commitment in two di erent ways. We follow [
All parties accept a set of verifying keys for the PSPs: P = fP:vkg Onboarding Each party i runs (sk; vk) KGen( ) then broadcasts vk to all parties.
Other parties stores vk associated with the party ID. In this section we describe the protocol DIF that securely realizes the ideal functionality FCIF. The security of DIF will also be sketched accordingly.
Initialization and Onboarding. The protocol initialization is as simple as all parties set the initial round t = 0 and the set of invoices I and payments M to be initially empty. The set of verifying keys of the PSPs is also xed at the beginning of the protocol P = fP:vkg5. To onboard a party, it requires that party to generate a pair of signing key sk and verifying key vk. The party then simply broadcasts the verifying key vk to be stored by all other parties. The initialization is illustrated in Fig. 5.
Invoice Registration and Acknowledgement. As shown in Fig. 6, to register an invoice into the protocol: 1. The seller S rst does the same as in the ideal functionality, i.e. composes a standardized invoice document D, extracts all the important information I: = (I:hash, I:sell I:buy, I:val, I:exp) from the invoice document. We recycle the notation map(Com; (s1; : : : ; sn)) to indicate the sequence (Js1K; : : : ; JsnK). The information is then committed into map(Com; I: ) and JI; map(Com; I: )K. 2. The initial buyer status I: B = sent is also committed into JI: BK. 3. The seller S then broadcasts JI: BK together with JI; map(Com; I: )K and only sends the private data to the buyer B. 4. The PSP P also receives map(Com; I: ), I:sell, I:val from the seller S. 5. The buyer B signs the invoice JI; map(Com; I: )K with sk to obtains the signature I, updates the buyer status to acked (to be committed to JI: B = ackedK). 6. The buyer B sends the updated status I: B = acked to seller S then broadcasts the tuple ( I, JI: B = ackedK) together with JI; map(Com; I: )K. 7. The other parties verify the signature before accepting the data. 8. Finally seller S forwards I and I: B = acked together with JI; map(Com; I: )K to factor
F if I is factored to F .
We note that (1) whenever a party sends some private data to another party in a step in the protocol, the corresponding randomness used for the commitment of that private data is also included. Hence we omit the randomness in the protocol description for simplicity; (2) whenever a party receives some private data from another party, a check for data consistency 5We assume the PSPs have run key generation and obtain a pair of signing key P:sk and verifying key P:vk before the protocol starts. Invoice Acknowledgement Buyer B upon receiving the private data from the seller S; 1. signs and broadcasts I = Sig(sk; JI; map(Com; I: )K) together with JI; map(Com; I: )K; 2. update I: B = acked; 4. sends I: B = acked togethJIe:r wBit=h aJcIk;emdKatpo(gCeotmh;eIr:w)ithtoJIS;emllaerp(SC;om; I: )K; 3. commits and broadcasts
K
Seller S forwards I and I: B = acked together with I:hash to factor F if I is factored to F . between the private data and the public commitments must be carried out; and (3) whenever a signature veri cation or a check regarding the data consistency fails, the complaining party open the private data to show the inconsistency and the protocol is aborted6. Invoice Factoring and Proposal Acknowledgment. We illustrates the protocol steps to factor an invoice in Fig. 7.
1. As in the ideal functionality, S and F must rst negotiate out-of- band the factoring term, i.e. the advanced amount I:amount. The out-of-band negotiation requires S to send the invoice document D to the factor F . 2. The seller S then can register an invoice proposal into the protocol by committing and broadcasting JI:f actor = F K, JI:amount = vK, JI: F = factor sentK together with JI; map(Com; I: )K. 3. As usual, S forwards the private data I: , I: B, I:f actor, I:amount and I: F to F . 4. The other parties only accept the new proposal if there is no previous proposal, i.e. there is no tuple (JI:f actorK, JI:amountK, JI: F K) for JI; map(Com; I: )K. 5. The PSP P is also involved in this step: (a) It is required to generate a signature 0I on the invoice proposal JI:hash; I:f actor; vK. (b) P then sends the signature 0I to S who will forward it to F . (c) The factor F then can acknowledge the proposal similarly to the invoice acknowledgment, i.e. commits and broadcasts JI: F = factoredK together with JI; map(Com; I: )K while sending I: F = factored together with JI; map(Com; I: )K to Seller S and the PSP P .
Payment Registration and Invoice Settlement. The protocol steps for payment handling is described in Fig. 8. The invoice expiration is moderated by the current assignee of the invoice, let it be the seller S or the factor F , by committing and broadcasting JI: B = expiredK together with JI; map(Com; I: )K. The private data is sent to the buyer B and the PSP P is also noti ed. The PSP P has an important role in nalizing invoice proposals and invoice settlements. 1. As in the ideal functionality, P receives payment out-of-band from a payer and processes the payment with the stored information.
6The private data and the public commitments can be then used for post-protocol dispute resolution. Invoice Proposal Registration Seller S Invoice Proposal Acknowlegdement Factor F upon receiving the private data from Seller S 1. extracts the factoring term, i.e. v, from the agreement with the factor F ; 2. commits and broadcasts JI:f actor = F K, JI:amount = vK, JI: F = factor sentK together with 3. sJeIn;dmsaIp:(fCaocmto;Ir:=)F; , I:amount = v, I: F = factor sent together with JI; map(Com; I: )K to factor
K
F ; 54.. soebntdaisnmsap0I(C=omS;igI(:sk);,JJII:f:haacsthorKjI=:fFa,ctIo:rajmvKo)ufnrtom= PvStPogPethaenrdwfiotrhwJaIr;dmsiatpt(oCofamc;tIo:r F)K; to PSP P All parties reject the proposal if there is already a tuple (JI:f actorK, JI:amountK, JI: F K) for JI; map(Com; I: )K.
Factor F checks 1 = Vf(vk; 0I; JJI:hashKjI:f actorjvK).
1. update I: F = factored; 2. commits and broadcasts JI: F = factoredK together with JI; map(Com; I: )K; 3. sends I: F = factored together with JI; map(Com; I: )K to Seller S; 4. sends map(Com; I: ), I:f actor = F , I:amount = v together with JI; map(Com; I: )K to PSP P ; We sketch here the key step of the security proof. As in standard simulation-based security proofs, we must exhibit an e cient simulator interacting with the ideal functionality FCIF that is able to fake the view of any e cient adversaries corrupting a subset I of the untrusted parties in an execution of protocol DIF.
On a very high level, our simulator S works as follows. During the simulation, it commits to zero values for each commitment forwarded by an honest party in the real protocol and relies on the ideal functionality FCIF to register, acknowledge invoices, invoice proposals and payments.
The hiding property of the commitment scheme implies that the above simulation is indistinguishable to the view generated in a mental experiment where the simulator S is given the real inputs corresponding to each honest party. The only di erence between this mental experiment and a real protocol execution is that in the former experiment the market evolves using the data held at the beginning by each corrupted party, whereas in the latter experiment the adversary can try to cheat and fake the data of a corrupted party (e.g., by committing or sending wrong value). However, the binding property of the commitment scheme and the security of the digital signature scheme ensure that such cheating attempts only succeed with a negligible probability.
This allows us to conclude that the view simulated in the ideal world (with the functionality FCIF) is computationally indistinguishable from the view in a real execution of the protocol, thus establishing the security of DIF. 7
We report here on the proposed implementation in the UNBIAS project7.
The ultimate goal of this network is to digitize and digitalize the invoicing process amongst buyers and sellers. UNBIAS de nes following roles: Seller, Buyer, Payment Switch/PSP, Factor.
The rst three roles are what we see as the core roles of the network and they form the basis on which the UNBIAS initiative is built. Factor is the role which will help achieve the objective of the UNBIAS is that is to enable easy access to funds for SMEs. There are more roles possible in this network and would be considered to be added in future.
The Distributed ledger is hosted by the Peer Nodes (Dense Compute) and each peer node has copy of ledger locally. Peer nodes are the nodes which do the heavy tasks like doing consensus and verifying commitments. Since these tasks are quite resource intensive, the systems running the node have to be high con guration hardware to support the load. Also only these nodes have the copy of ledger so eventually it would need high amount of storage preferably with high performance.
Apache Kafka is the consensus protocol for Hyperledger fabric. Kafka is primarily a distributed, horizontally-scalable, fault-tolerant, commit log. A commit log is basically a data structure that only appends. No modi cation or deletion is possible, which leads to no read/write locks, and the worst case complexity O(1). There can be multiple Kafka nodes in the blockchain network, with their corresponding Zookeeper ensemble. Veri cation of commitment is necessary to trust the validity of the invoice transactions reported on the ledger. An hash has to be veri ed against the hashes in the ledger and its chain to the root it is an resource intensive task. Hence it should be run on peer node. 8
The market for invoice factoring can signi cantly bene t from the deployment of distributed ledger solution. A blockchain would make it possible for factors to check whether an invoice has been already factored (double pledging) without forcing all stakeholders (banks, factors, etc.) to share and disclose their data.
In this paper we have described the security requirements and all key operations for a secure, fully distributed Invoice Factoring Market. Our distributed, asynchronous protocol simulates the centralized functionality under the assumption of the availability of a distributed ledger and o ers security with abort (in absence of a honest majority).
Looking at the rst results from the introduction of the Italian obligation of electronic invoicing8, there seems to be a reduced propensity of Italian companies to rely on their bank(s) as a provider of services for electronic invoicing. In an economic system characterized by multibanked companies9, the tight bond with a single bank is experienced more as a penalty than as a real advantage and companies prefer the use of intermediaries specialized in electronic invoicing. Given this scenario, then the adoption of electronic invoicing could only be an incentive for the development of a blockchain dedicated to the certi cation of the uniqueness and source of the invoices, without restricting the potential scope of the blockchain itself. 8http://www.gazzettaufficiale.it/eli/id/2018/10/23/18G00151/sg.
9An Italian company may use on average the services of three-four banks and some companies more than a dozen.