Porta Whitepaper

03.11.2021 version 1 — Robert Marshall

Abstract— Traditional blockchain architectures combine the functionality of block authoring and finalisation into a single runtime. Overtime, blockchain runtimes are expanded to facilitate a myriad of industry technologies and each technology requires its own set of configurations to function. While these blockchain configurations provide the basis for new runtime functionalities and new industries to form upon them, they also intrinsically harbour deficiencies that detriment the operation of the other runtime technologies previously integrated into the system.

For instance, on-chain storage of NFT's require large data files to be transacted. To create block sizes that allow large data, the block time of the network must be increased, lowering the TPS (transactions per second) of the network. In contrast to this, cryptocurrency transactions require small data files and small block sizes to generate the shortest block time possible and achieve the highest TPS. Therefore, data storage and fund transfer are technologies whose blockchain configurations are in contradiction to each other. Any blockchain integrating these technologies must, therefore, be weak in both and strong in neither.

The Substrate framework offers a relay chain and parachain architecture that separates the authoring and finalisation process, effectively creating independent runtimes operating on individual blockchain configurations that cooperate in a single ecosystem centred around a relay chain. Parachains act as standalone runtimes through independent blockchain configuration. Parachain's consensus model BABE is compatible with the Byzantine finality gadget of GRANDPA, so Porta utilises this technology to create an ecosystem of truly independent, industry-optimised blockchains that are inherently compatible and interoperable at the consensus layer.

Porta uses the relay chain and parachain functionality provided by the Substrate framework as the basis for its architectural design.

INTRODUCTION

One size fits all, but it doesn't fit them well. Standalone blockchains that try to accommodate multiple industry technologies suffer from the trade-offs intrinsic to the configurations of those technologies.

Substrate's relay chain architecture and Porta's unique tokenomic design allow for scalability while alleviating the need for increased complexity, this keeps barriers to entry low and facilitates mass adoption.

Porta is able to utilise the Substrate framework's core runtime pallets to enable the following features:

Security.
Relay chain Nominated Proof-Of-Stake utilising BABE and GHOST.
Runtime Upgrade.
Runtime logic is stored on-chain as WebAssembly that can overwritten.
Governance and Democracy.
Council members, Technical Committee members and Community members form a decentralised autonomous organisation through the implementation of voting mechanisms.
Smart Contracts.
Rust-based, Substrate smart contract pallet Ink!
Staking and Nomination
Relay chain validator nodes can stake PORTA tokens. All other token holders can use their PORTA tokens to nominate validators and share in their rewards.

ECOSYSTEM

Porta's ecosystem has a high security relay chain that honours the core ethos of decentralisation through pooled security. Connected to the relay chain are parachains optimised for industry sectors. Companies can take advantage of this configuration by leasing parachain slots to fulfil their business objectives.

Optimized parachains:

The NFT Marketplace:

The Porta ecosystem provides the ability for users to mint NFT's for images, audio and games, this links to a frontend marketplace enabling those NFT's to be traded.

An overview of the Ecosystem:

Porta's current roadmap involves the implementation of optimised parachains for Decentralised Finance and the Gaming Industry. Here is a theoretical construct of how the ecosystem may look in the near future.

ARCHITECTURE

2.1. Architectural Overview

Figure 1. a high-level overview of Relay chain architecture.

Figure 2. a high-level overview of Parachain architecture.

2.2. Consensus

The Proof-of-Work (PoW) consensus mechanism uses computation power to produce blocks. To solve the high energy consumption of PoW, Proof-of-Stake (PoS) was developed.

Traditional PoS block production is dependent on token holdings and, while PoS developers usually have a proponent for equitable participation in a decentralized manner, most projects end up proposing some level of centralized operation where the number of validators with full participation rights is limited. The wealthiest validators thus have the greatest influence in the PoS network as they are the most staked. Traditional PoS systems required advanced technical knowledge of software and hardware to configure, and validator pools were often off-chain.

The next generation of PoS solved this problem by moving validator pools on-chain and allowing token holders to vote for validators to represent them, this was done through staking tokens directly with the validator. This mechanism was called Nominated Proof-of-Stake (NPoS) and it is the mechanism Porta uses.

The roles of validators and nominators maximize chain security.

Validators assume the role of producing new blocks in BABE, validating parachain blocks, and guaranteeing finality.

Nominators back active validators and validator candidates with their stake.

2.3. Hybrid Consensus

Hybrid consensus involves GRANDPA and BABE.

GRANDPA: GHOST-based Recursive ANcestor Deriving Prefix Agreement
BABE: Blind Assignment for Blockchain Extension

Hybrid consensus combines the finality gadget from the block production mechanism to achieve the benefits of probabilistic finality and provable finality.

Probabilistic Finality: the ability to always produce new blocks
Provable Finality: having a universal agreement on the canonical chain with no chance for reversion

Hybrid consensus avoids the drawbacks of the independent mechanisms.

the chance of unknowingly following the wrong fork in probabilistic finality
the chance for "stalling" - not being able to produce new blocks - in provable finality.

By combining these two mechanisms, Porta allows for blocks to be rapidly produced, and the slower finality mechanism to run in a separate process to finalize blocks without risking slower transaction processing or stalling.

2.4. Block production

2.4.1. BABE

BABE is the block production mechanism that runs between the validator nodes and determines the authors of new blocks. BABE assigns block production slots to validators according to stake and a randomness cycle. Validators in Porta will participate in a lottery in every slot that will tell them whether or not they are the block producer candidate for that slot. Slots in Porta's network represent units of 6 seconds. Because of this randomness mechanism, multiple validators could be candidates for the same slot. Other times, a slot could be empty, resulting in inconsistent block time.

When multiple validators are block producer candidates in a given slot, the validator whose block is broadcast to most of the network the quickest wins and receives most of the reward. During this period multiple chains exist and Finality is the process whereby one chain is chosen and the other are discarded.

When no validators have rolled low enough in the randomness lottery to qualify for block production, a slot can remain seemingly blockless. We avoid this by running a secondary, round-robin style validator selection algorithm in the background. The validators selected to produce blocks through this algorithm always produce blocks, but these secondary blocks are ignored if the same slot also produces a primary block from a VFR-selected validator. Thus, a slot can have either a primary or a secondary block, and no slots are ever skipped.

2.4.2. Finality

PoW is only able to achieve the notion of probabilistic finality and reach eventual consensus. Probabilistic finality means that under some assumptions about the network and participants, if we see a few blocks building on a given block, we can estimate the probability that it is final. Eventual consensus means that at some point in the future, all nodes will agree on the truthfulness of one set of data.

Finality gadgets such as GRANDPA (GHOST-based Recursive ANcestor Deriving Prefix Agreement) are designed to give stronger and quicker guarantees on the finality of blocks. Once finalised, they cannot be reverted after some process of Byzantine agreements has taken place. The notion of irreversible consensus is known as provable finality.

2.4.3. GRANDPA. a Byzantine Finality Gadget.

GRANDPA (GHOST-based Recursive ANcestor Deriving Prefix Agreement) is the finality gadget that is implemented for the Porta Relay Chain. GRANDPA reaches agreements on chains rather than blocks, greatly speeding up the finalization process, even after long-term network partitioning or other networking failures. Finality is reached when 2/3 of the nodes attest to a chain containing a certain block.

2.4.4. Fork choice rule algorithm

BABE must always build on the chain that has been finalized by GRANDPA. When there are forks after the finalized head, BABE provides probabilistic finality by building on the chain with the most primary blocks.

Figure 4. fork choice rule diagram.

In the above image, the black blocks are finalized, and the yellow blocks are not. Blocks marked with a "1" are primary blocks; those marked with a "2" are secondary blocks. Even though the topmost chain is the longest chain on the latest finalized block, it does not qualify because it has fewer primaries at the time of evaluation than the one below it.

ACTORS

3.1. Nominator

You can earn PORTA by nominating one or more validators.

Nominators secure the Relay Chain by selecting good validators and staking PORTA.

Validator nodes that follow the rules of the network get rewarded and the nominator shares in those rewards.

Bad performing validators get slashed and this will result in losing some of your PORTA tokens.

3.2. Validator

Validators secure the Relay Chain by staking PORTA, validating proofs from collators and participating in consensus with other validators.

These participants play a crucial role in adding new blocks to the Relay Chain and, by extension, to all parachains. This allows parties to complete cross-chain transactions via the Relay Chain. The Relay Chain validators guarantee that each parachain follows its unique rules and can pass messages between shards in a trust-free environment.

3.3. Council

The council is an on-chain entity comprising several elected accounts who represent passive stakeholders. The council control the treasury fund, propose sensible referenda, cancel malicious referenda, and elect the technical committee.

For a referendum to be proposed by the council, a strict majority of members must be in favour, with no member exercising a veto. Vetoes may be exercised only once by a member for any single proposal; if, after a cool-down period, the proposal is resubmitted, they may not veto it a second time.

Council motions which pass with a 3/5 (60%) super-majority - but without reaching unanimous support - will move to a public referendum under a neutral, majority-carries voting scheme. In the case that all members of the council vote in favour of a motion, the vote is considered unanimous and becomes a referendum.

Figure 5. council election diagram.

3.4. Technical committee

The Technical Committee is composed of individuals with proven technical knowledge. Members are added or removed from the Technical Committee via a simple majority vote of the Council.

The Technical Committee can produce emergency referenda which are fast-tracked for voting and implementation. These are used for emergency bug fixes or rapid implementation of new battle-tested features into the runtime.

Fast-tracked referenda are the only type of referenda that can be active alongside another active referendum. Thus, with fast-tracked referenda it is possible to have two active referendums at the same time. Voting on one does not prevent a user from voting on the other.

4.1. Nominated Proof-Of-Stake (NPoS)

Nominated Proof-of-Stake encourages PORTA holders to participate as nominators, this gives a financial incentive to keep the network secure. Nominators can back up to 16 validators by locking tokens as collateral to receive staking rewards.

The staking system pays out rewards equally to all validators regardless of stake. The amount staked by a validator does not influence the amount of block rewards it receives. However, there is a probabilistic component to reward calculation (discussed below), so rewards may not be exactly equal for all validators in a given era.

Distribution of the rewards are pro-rata to all stakers after the validator payment is deducted. In this way, the network creates incentives for the nomination of lower-staked validators to create an equally-staked validator set.

In staking, you can be either a nominator or a validator.

4.1. Nomination

Users nominate validators by staking PORTA tokens. In the next era, the validators that have the most PORTA backing them become active validators.

There are no particular requirements to become a nominator, though we expect each nominator to carefully track the performance and reputation of the validators they back. Nominating is not a "set and forget" operation.

Once the nomination period ends, the NPoS election mechanism takes the nominators and their associated votes as input, and outputs a set of validators. This "election solution" has to meet certain requirements, such as maximizing the amount of stake to nominate validators and distributing the stake backing validators as evenly as possible. The objectives of this election mechanism are to maximize the security of the network and achieve fair representation of the nominators.

Nominators must monitor their validators' performance (uptime), keeping an eye on changing commission rates because a validator can change the commission rate at any time.

4.2. Validators

Validators produce new block candidates in BABE, vote and come to consensus in GRANDPA, validate the state transition function of parachains.

4.3. Rewards

Porta produces block rewards every six seconds. Rewards are recorded per era and are stored on the validators statistics which holds data for the last 84 eras.

Rewards are calculated based on era points, which have a probabilistic component. In other words, there may be slight differences in your rewards from era to era, and even amongst validators in the active set at the same time. These variations should cancel out over a long enough timeline.

4.3.1 Claiming Rewards

In order to be paid your staking rewards, someone must claim them for each validator that you nominate. Staking rewards are kept available for 84 eras, which is 84 hours on PORTA.

If you go to the Staking payouts page on Polkadot-JS, you will see a list of all validators that you have nominated in the past 84 eras and for which you have not yet received a payout. Each one has the option to trigger the payout for all unclaimed eras. Note that this will pay everyone who was nominating that validator during those eras, and anyone can call it. Therefore, you may not see anything in this tab, yet still have received a payout if somebody has triggered the payout for that validator for that era.

Validators can set a commission, this is a proportion of the reward that is not shared with the nominators.

This cut is a percentage of the block reward, not an absolute value. After the commission gets deducted, the remaining portion is based on their staked value and split between the validator and all of the nominators who have voted for this validator. For example, assume the block reward for a validator is 10 PORTA. A validator may specify validator_commission = 50%, in which case the validator would receive 5 PORTA. The remaining 5 PORTA would then be split between the validator and their nominators based on the proportion of stake each nominator had. Note that validators can put up their own stake, and for this calculation, their stake acts just as if they were another nominator.

Rewards can be directed to the same account (controller), to the stash account (and either increasing the staked value or not increasing the staked value), or to a completely unrelated account. By using the Extrinsics tab (Developer -> Extrinsics -> Staking -> Bond) you can also send rewards to "None", effectively burning them. It is also possible to top-up / withdraw some bonded PORTA without having to un-stake all staked PORTA.

GOVERNANCE

Porta uses a sophisticated governance mechanism whose goal is to ensure that the majority of the stake can always command the network. To do this, we provide several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. All changes to the protocol must be agreed upon by stake-weighted referenda.

5.1. Mechanism

To make any changes to the network, the idea is to compose active token holders and the council together to administrate a network upgrade decision. Both the public (token holders) and the council can make proposals, and all proposals lead to a referendum where all token holders have the right to vote.

5.1.1. Referenda

Referenda are stake-based voting schemes. Each referendum has a specific proposal associated with it that takes the form of a privileged function call in the runtime (that includes the most powerful call: set_code, which can switch out the entire code of the runtime, achieving what would otherwise require a "hard fork").

Referenda are discrete events, have a fixed period where voting happens, and then are tallied and the function call is made if the vote is approved. Referenda are always binary; your only options in voting are "aye", "nay", or abstaining entirely.

Referenda can be started in one of several ways:

Publicly submitted proposals;

Proposals submitted by the council, either through a majority or unanimously;
Proposals submitted as part of the enactment of a prior referendum;
Emergency proposals submitted by the Technical Committee and approved by the Council.

All referenda have an enactment delay associated with them. This is the period between the referendum ending and, assuming the proposal was approved, the changes being enacted.

Emergency proposals deal with major problems with the network that need to be "fast-tracked". These will have a shorter enactment time.

5.1.1.1 Public Referenda

Any account can propose a referendum by depositing the minimum amount of tokens.

A proposal can be seconded by someone depositing the same amount of tokens.

The proposal with the highest amount of bonded support will be selected to be a referendum in the next voting cycle.

There can be a maximum of 100 public proposals in the proposal queue.

5.1.1.2 Council Referenda

Types of Council Referenda:

Unanimous Council - When all members of the council agree on a proposal, it can be moved to a referendum. This referendum will have a negative turnout bias (that is, the smaller the amount of stake voting, the smaller the amount necessary for it to pass.

Majority Council - When agreement from only a simple majority of council members occurs, the referendum can also be voted upon, but it will be majority-carries (51% wins).

There can only be one active referendum at any given time, except when there is also an emergency referendum in progress.

5.1.1.2 Voting Timetable

Every 28 days a new referendum will come up for a vote, assuming there is at least one proposal in one of the queues. There is a queue for Council-approved proposals and a queue for publicly submitted proposals. The referendum to be voted upon alternates between the top proposal in the two queues. The "top" proposal is determined by the amount of stake bonded behind it.

5.1.1.3 Voting on a referendum

To vote, a voter must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. It is possible to vote without locking at all, but your vote is worth a small fraction of a normal vote, given your stake. At the same time, holding only a small number of tokens does not mean that the holder cannot influence the referendum result, thanks to time-locking.

5.1.1.2 Tallying

Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use the following table for reference.

Entity	Metric
Public	Positive Turnout Bias (Super-Majority Approve)
Council (Complete agreement)	Negative Turnout Bias (Super-Majority Against)
Council (Majority agreement)	Simple Majority

Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let us use the public proposal as an example, so the Super-Majority Approve formula will be applied.

approve - the number of aye votes
against - the number of nay votes
turnout - the total number of voting tokens (does not include conviction)
electorate - the total number of PORTA tokens issued in the network

Super-Majority Approve:

A positive turnout bias, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below.

Super-Majority Against:

A negative turnout bias, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below.

Simple-Majority:

Majority-carries, a simple comparison of votes; if there are more aye votes than nay, then the proposal is carried, no matter how much stake votes on the proposal.

TREASURY

The treasury is a pool of funds that can be spent by the council for the purpose of funding improvements to the network. When a stakeholder wishes to propose a spend from the Treasury, they must reserve a deposit of at least 5% of the proposed spend. This deposit will be slashed if the proposal is rejected and returned if it is accepted.

Proposals may consist of:

Infrastructure deployment and continued operation.
Network security operations (monitoring services, continuous auditing).
Ecosystem provisions (collaborations with friendly chains).
Marketing activities.
Community events and outreach.
Software development (wallets and wallet integration, clients and client upgrades).

The Treasury is ultimately controlled by the Council, and how the funds will be spent is up to their judgment.

6.1. Funding the Treasury

The Treasury is funded from different sources:

Slashing: When a validator is slashed for any reason, the slashed amount is sent to the Treasury with a reward going to the entity that reported the validator (another validator). The reward is taken from the slash amount and varies per offence and number of reporters.
Transaction fees: A portion of each block's transaction fees goes to the Treasury, with the remainder going to the block author.
Parathreads: Parathreads participate in a per-block auction for block inclusion. Part of this bid goes to the validator that accepts the block and the remainder goes to the Treasury.

6.2. Creating a Treasury Proposal

The proposer has to deposit 5% of the requested amount or 100 PORTA (whichever is higher), the reason for this limit is to minimise spam proposals. This amount is burned if the proposal is rejected or refunded otherwise. Please note that there is no way for a user to revoke a treasury proposal after it has been submitted. The Council will either accept or reject the proposal, and if the proposal is rejected, the bonded funds are burned.

6.3. Tipping

Tips are funds sent from the treasury to reward users for work that has been done previously e.g., someone may have done work without requesting any funding through proposal, yet the community deem the work sufficient for reward, so they raise a tip request. Tips can be suggested by anyone and are supported by members of the Council. Tips do not have any definite value; the final value of the tip is decided based on the median of all tips issued by the tippers.

A tip will enter a closing phase when more than a half plus one of the tipping group have endorsed a tip. During that period, the other members of the tipping group can still issue their tips, but do not have to. Once the window closes, anyone can call the close_tip extrinsic, and the tip will be paid out.

There are two types of tips: public and tipper-initiated.

Tipper-initiated tips i.e., tips that a Council member published, do not have a finder's fee or a bond.
Public tips require a small bond that is dependent on the tip message length, although it is common for people to post a link to a URL that gives a long description of the reason for the tip request. Public tips carry a finder's fee of 20% which is paid out from the total amount.

IDENTITY

The identity pallet allows users to add personal information to their on-chain account and subsequently ask for verification of this information. The information is verified by registrars.

7.1. Registrars

Registrars can set a fee for their services and limit their attestation to certain fields. For example, a registrar could charge 1 PORTA to verify one's legal name or email address. When a user requests judgement, they will pay this fee to the registrar who provides the judgement on those claims. Users set a maximum fee they are willing to pay and only registrars below this amount would provide judgement.

7.1.1. Judgments

After a user injects their information on chain, they can request judgement from a registrar.

When a registrar provides judgement, they can select up to six levels of confidence in their attestation:

Unknown: The default value, no judgement made yet.
Reasonable: The data appears reasonable, but no in-depth checks (e.g. formal KYC process) were performed.
Known Good: The registrar has certified that the information is correct.
Out of Date: The information used to be good, but is now out of date.
Low Quality: The information is low quality or imprecise, but can be fixed with an update.
Erroneous: The information is erroneous and may indicate malicious intent.

A seventh state, "fee paid", is for when a user has requested judgement and it is in progress. Information that is in this state or "erroneous" is "sticky" and cannot be modified; it can only be removed by the complete removal of the identity.

Registrars gain trust by performing proper due diligence and would presumably be replaced for issuing faulty judgements.

SMART CONTRACT

9.1. Overview

Porta smart contracts are written in Rust using Ink!

ink! is a domain specific language for writing smart contracts in Rust and compiles to Wasm code. ink! has laid much of the groundwork for a new smart contract stack that is based on a Wasm virtual machine and compatible with Substrate chains.

Wasm. The Contracts pallet uses WebAssembly as its compilation target. Any language that compiles to Wasm can potentially be used to write smart contracts. Nevertheless, it is better to have a dedicated domain-specific language, and for that reason Parity offers the ink! Language.
Rent. Contracts must pay rent or else hold a deposit suitably large enough in order to justify its existence on-chain. When a contract does not uphold this, it may create what's called a tombstone which is a reference to the contract. In some conditions, the contract will be deleted outright along with its storage if it does not maintain these requirements.
Caching. Contracts are cached by default and therefore means they only need to be deployed once and afterward be instantiated as many times as you want. This helps to keep the storage load on the chain down to the minimum. On top of this, when a contract is no longer being used and the existential deposit is drained, the code will be erased from storage.

TOKENOMICS

Price appreciation of a token can create a barrier to entry and increase transaction fees within the network. In this way, traditional blockchains have the possibility to become a victim of their own success.

Porta's unique tokenomic structure solves this problem by allowing only the core currency PORTA to appreciate in value. Each sector-specific blockchain has its own cryptocurrency token that is pegged to the Dollar through a stablecoin liquidity pool, we collectively refer to these sector-specific tokens as 'sub-tokens'. As the sub-tokens are purchased from the liquidity pool, they increase in value. The peg is maintained by moving stablecoin liquidity between a sub-token pool and the PORTA liquidity pool. Thus, the value changes of the sub-tokens are reflected in the PORTA price. This approach creates a single point of price appreciate and a transparent investment structure.

So, let's see visually how this works.

For example purposes we will use USDC as the stablecoin, PORTA as the mainnet token and pGAME as the sub-token for Porta's custom parachain built for gaming company X.

Both PORTA and pGAME tokens have liquidity pairing with the same stablecoin USDC.

As pGAME tokens are purchased this alters the liquidity pool to make pGAME tokens more valuable temporarily. USDC tokens are then moved from the PORTA liquidity pool to the pGAME liquidity pool, this returns pGAME to its peg of $1 and increases the value of the PORTA token accordingly: less USDC is now in the PORTA liquidity pool while the amount of PORTA tokens has remained constant.

Step 1: the starting price of the tokens

Step 2: someone buys 50 pGAME tokens for 50 USDC

The price of pGAME is now technically $3.

Step 3:

50 pGAME tokens are newly minted and moved to the pGAME liquidity pool.

50 USDC is moved from the pGAME liquidity pool to the PORTA liquidity pool.

The price of pGAME is now pegged back to $1 and PORTA token price has appreciated by $0.50 cents to $1.50.

The same process holds true for a sale of pGAME tokens.

Step 1: the starting price of the tokens

Step 2: someone sells 50 pGAME tokens for 50 USDC

The price of pGAME is now technically $0.33.

Step 3:

50 pGAME tokens are moved out of the pGAME liquidity pool burned.

50 USDC is moved from the PORTA liquidity pool to the pGAME liquidity pool.

The price of pGAME is now pegged back to $1 and PORTA token price has depreciated by 50 cents to $0.50.

Please note that the liquidity pools will be much higher and won't effect the price as much as mentioned here.

While a sale of pGAME tokens does result in a depreciation in the price of PORTA, we believe that this method of internal arbitrage, especially when applied to multiple company parachains, will cause the PORTA token price to significantly increase over time.

We are also willing to discuss different pricing models for companies whereby their sub-token is not linked to the price of PORTA and appreciates in value independently. This will, however, incur higher fees for leasing a parachain slot.

CONCLUSION & PERSPECTIVES

The runtime-independence provided by Substrate's parachain framework joined with the cohesion provided by the relay chain Byzantine finality gadget, provides the functionality necessary to bring to Porta's vision of an ecosystem of independent company blockchains natively communicating within a single ecosystem to life. When this architectural design is combined with the unique tokenomics presented in this white paper, the ecosystem provides a central point of price appreciation without any increased fees or barriers to entry being applied to the parachains. It is, therefore, considered that Porta's implementation of the parachain architecture, provided by Substrate, is a design structure most conducive to present market conditions enabling companies to enter the crypto space with minimal cost, confusion and technical undertaking.

REFERENCES