Trying to understand the tech that the BOE is asking for last year would have been alot harder....but now its no longer a problem..due to the info and knowledge we have all gained from MPC Partisia tech.
Part 2.......
https://www.bankofengland.co.uk/-/media/boe/files/paper/2023/the-digital-pound-technology-working-paper.pdfc) Distributed data analysis
Distributed data analysis refers to the processing of distributed data sets by multiple parties
in a privacy-preserving manner. Some techniques include:
• Secure multi-party computation (SMPC), which enables multiple entities to jointly
process or perform calculations on distributed datasets without sharing data with each
other. This technique could minimise sensitive data sharing in the ecosystem and
Encrypted data processing
Encrypted data processing allows one party to process data held in encrypted form by
another party. Some techniques include:
• Homomorphic encryption, which allows parties to process encrypted data without first
having to decrypt it. The data remain encrypted at all times, reducing the likelihood of
sensitive data disclosure or information compromise in the ecosystem. This technique
might help PIPs share and process sensitive data in a privacy-preserving manner, for
example for anti-money laundering (AML) compliance.
(Partisia MPC got HE built in)Threats may evolve during the potential design, build and operational lifetime of the
CBDC system. New threats aimed specifically at CBDC might also emerge.
Threats generally evolve and adapt to technology innovation, and to changes in user
preferences and behaviour. Quantum computing is one such threat. Quantum computers
could provide speed, efficiency, and significantly more processing power than conventional
computers. These advances could pose risks to conventional cryptography widely used to
secure data and systems today.
In recognising these future risks, the Bank also acknowledges that cryptography primitives
break or become obsolete over time. Therefore, the quantum computing threat is an
additional layer of risk that the Bank must factor into its CBDC design thinking. The Bank will
work with partners to better understand the future risks posed to CBDC by quantum
computing
(Partisia MPC is Quantam resistant)The CBDC system must be operational 24/7/365.
As a retail payment infrastructure, the CBDC service would be
available to end users 24 hours a day, every day of the year.
Planned upgrades and maintenance should not affect service
availability.
Anticipate
Withstand and
respond
The CBDC system must have a very high degree of availability.
Although capable of operating 24/7/365, CBDC might, in very rare
circumstances, be subject to outages or disruption, much like existing
retail payment services. CBDC must be designed to minimise or avoid
service interruption.
Uptime is the time that a system is available and operational. Current
RTGS and CHAPS services have a target uptime of at least 99.95%,23
and that would constitute a minimum expectation for Bank-managed
CBDC infrastructure. H
(Partisia MPC 100% uptime since going live 2.5yrs ago)As retail payment infrastructure, CBDC will need to meet exacting performance
requirements in terms of speed, capacity and certainty.
A CBDC system would need to handle a high number of transactions to accommodate peak
demand, alongside confirming and settling transactions as quickly as possible.
While requirements for throughput and speed will differ depending on the specific CBDC use
case and payment type, the Bank will examine solutions for enabling a high-performance
CBDC system. An example of how requirements differ by use cases is set out below:26
Example use cases
• If using CBDC to pay in-store, fast authentication and transaction time is important.
Transactions that confirm within a couple of seconds would suffice for this purpose.
• If using public transport, speed becomes even more important. For example, when
paying at a ticket barrier, confirmation speed may need to be under a second to
prevent queues and congestion.
Transaction speed of under one second for a standard single destination payment
appears necessary.
Some categories of payments would require a faster transaction speed than others. CBDC
payments may need to confirm in under one second in order to accommodate all of these
categories. Confirmation and settlement of transactions in under one second is possible, but
when combined with a high volume of transactions in a production environment, it might
present challenges for the performance and capabilities of the core ledger. The Bank plans to
examine different technology choices, including those relating to ledger technology, to
understand the extent to which they can deliver on our likely requirements for transaction
speed.
Throughput of approximately 30,000 transactions per second may be necessary. The
Bank will also explore a more ambitious capacity of approximately 100,000
transactions per second, in order to accommodate future payment needs.
The Bank estimates that throughput of approximately 30,000 transactions per second might
be needed for a viable CBDC system. This capacity would allow for enough capability to
support all retail transactions in the UK on any given day. It would also provide flexibility to
cater for an increase in transaction volume over time, alongside supporting the addition of
further payment types, such as wage payments and foreign exchange.
However, as potential CBDC use cases develop, CBDC throughput demands may increase.
The Bank will assess ledger designs that accommodate much higher capacity, including
exploring whether it is feasible for a production system to reach up to approximately 100,000
transactions per second.
A CBDC system should be capable of scaling to accommodate increases in payment
volume without negatively impacting overall performance.
Scalability is an important aspect of performance. The use cases for CBDC may evolve over
time. For example, functionality, such as micropayments, might increase throughput
demands. Therefore, it is important that any CBDC system is built in a way that caters for
such increases in demand.
(Partisia MPC, instant finalization and unlimited throughput)Vertical or horizontal scaling should be considered to ensure that the core ledger is
able to accommodate future demands and use cases.Vertical scaling, whereby computational power of the existing infrastructure is upgraded, is
one method to cater for increased payment volume.
Horizontal scaling is an alternative,
where more machines are added to the resources responsible for payment processing.
Generally seen as more desirable, horizontal scaling should be considered in the system
design to ensure that the core ledger is capable of accommodating the addition of new
computational resources.(Partisia MPC the only Blockchain in the world to have true Horizontal scaling Complete sharding.
Traditional blockchains grapple with scalability issues, impeding real-time finalization and usability during high traffic. Partisia Blockchain confronts this challenge head-on by adopting a revolutionary approach. We have re-engineered the traditional method, enabling horizontal scaling and boasting a rapid .3-second finalization time in normal conditions. Our network comprises multiple blockchains, each autonomously producing blocks, creating an unparalleled scalability model. Moreover, our unique BFT consensus mechanism ensures “speed of light” finalization. For in-depth insights into this architecture, refer to our yellow paper.)
https://partisiablockchain.com/partisia-blockchains-complete-sharding/3.6: Energy usage
Summary
• CBDC infrastructure should be energy efficient and designed in a way which
minimises any impact on the environment.
• A UK CBDC would not use the energy-intensive technologies used by some crypto
assets
A UK CBDC would not use the energy-intensive technologies used by some crypto
assets.
A UK CBDC would be fundamentally different to a crypto asset. It would not use the energyintensive technologies, such as proof of work,27 that underpin some crypto assets
(Partisia MPC, At Partisia Blockchain, sustainability is not just a buzzword, but an integral part of our portfolio. We firmly believe that blockchain technology has the potential to drive positive change and contribute to a sustainable future. Through our range of solutions, we prioritize sustainability and align our projects with ESG and UN SDG goals.
https://medium.com/partisia-blockchain/driving-sustainable-impact-partisia-blockchains-commitment-to-sustainability-esg-and-un-sdg-d25cf4abdad2A CBDC ecosystem would include different actors and activities. Some activities and
components would be operated by the Bank, while others would be operated by third parties.
The interactions and dependencies between these components and activities would require
the development of scheme rules, as well as operating and technical standards.
The use of centrally governed, distributed database technologies might be a more
efficient and appropriate approach than the use of DLT solutions. However, the Bank
will continue to assess a range of different approaches and will closely monitor
ongoing developments in ledger technology.
A number of features of DLT may not be applicable to, or necessary for, a CBDC use
case.
DLT approaches might impose undesirable decentralisation of other aspects of a system,
such as governance or administration. DLT features that support information exchange in a
trustless network may not be necessary for a CBDC use case. These features might also
introduce unnecessary technical complexity. Further, it may also be possible to achieve some
of the benefits of DLT, such as resilience, redundancy and security, via alternative and wellestablished data management strategies, using distributed, centrally managed databases.
A white paper from the UK’s National Cyber Security Centre (NCSC)31 concluded that DLT is
only likely to be useful in circumstances where all the following statements are true:
a) Multiple entities need to be able to write data.
b) There is a lack of trust between the entities writing data.
c) There is no trusted central authority that can write data on behalf of the entities.If any one of the above statements is assessed to be false, then the NCSC considers that a
‘conventional technology, like a database, is likely to be more appropriate’.
Based on the Bank’s current thinking on requirements for the core ledger, the use of centrally
governed, distributed database technologies, might be a more efficient and appropriate
approach than the use of DLT solutions. However, the Bank will continue to assess a range
of approaches, and continue to monitor ongoing technology developments.
(None of the above statements are false when applied with Partisia MPC)
Ethereum model
Blockchains, such as Ethereum, have popularised smart contracts by allowing contracts to be
hosted, orchestrated and executed on the blockchain itself via the Ethereum Virtual Machine
(EVM).
The Ethereum approach would require the Bank to host and orchestrate wide-ranging
business logic on behalf of others, in the form of smart contracts. Given our aim to provide
the minimum necessary functionality for CBDC, this activity is best left to the private sector.
Hosting business logic also creates a number of reputational risks and potential conflicts. It
could also create technical challenges or inhibit the performance of the core CBDC system.
Avalanche model
Avalanche is a popular blockchain that aims to segregate the smart contract platform from
the core transaction ledger. It addresses some of the performance constraints of the
Ethereum model by enabling increased volume for smart contract transactions while offering
many of the functionality benefits.
This architecture requires multiple ledgers to be hosted – at a minimum, one for processing
transactions that exchange digital assets or payments, and one for hosting smart contracts.
In the Avalanche model, the EVM is used for the smart contract platform. This enables some
interoperability with Ethereum applications, code, and its community of developers.
Segregating the smart contract platform from the core ledger may be one way to address the
additional performance demands while ensuring that simple payments are always fast and
available, but this would require us to host a smart contract platform and would expose the
Bank to operational risks and other considerations highlighted above.
Smart contract architectures may not be appropriate for the core CBDC system, but
some functionality might be enabled elsewhere in the ecosystem.
To ensure that the core ledger is as simple, resilient and performant as possible, and to
support private sector innovation,
the Bank considers that complex business logic for smart
contracts should not be hosted on the CBDC ledger.
This means that the Ethereum and Avalanche approaches to smart contracts may not be appropriate for a UK CBDC. However,
it might be possible for certain elements and functionalities of these approaches to be
enabled off-ledger by PIPs and ESIPs as part of the wider CBDC ecosystem.
During the forthcoming design phase, the Bank will continue to examine solutions, together
with the private sector, that enable smart contracts and interoperability with different
programmable platforms. Determining whether the CBDC system can support smart contract
functionality, while not compromising simplicity, resilience or performance in the core ledger
will remain our guiding principle in those experimentations.
Partisia MPC can do everyting ETH and AVAX can do, but better and it can do things that ETH and AVAX cannot....
The tech speaks for itself....Mcaps follow eventually...Oneday the Mcap of Partisia will be at least the same as AVAX and possibly as high as ETH...or higher than both.
