We are experiencing tremendous technology and community growth! Our latest newsletter covers the most important events of the past few weeks and other important updates!
We've been hard at work over the past couple of weeks; improving every phase of the project and making Pascal work better.
Our latest newsletter features the highlights of this period of time.
Secondly, Pascal solves the long-term blockchain “storage issue” by introducing deletable blockchain technology. This technology allows Pascal nodes to securely delete the blockchain beyond the last 100 blocks. By storing the flow of transactions rather than the infinite history, the Pascal network is the first (and only known) cryptocurrency that can theoretically run for infinite time at maximum throughput while requiring only constant storage. In this manner, Pascal achieves “infinite scalability”.
25 PASC Minted
Windows Classic GUI
Linux Classic GUI
Miner Infrastructure (GPU)
Dynamic PASA issuance
In-Protocol Coin-Mixing Protocol (L2)
DAO Voting Protocol (L2)
Token Protocol (L2)
Chat Protocol (L2)
Marketplace Protocol (L2)
DEX Protocol (L2)
GraphQL over SafeBox
Private Balances/Transfers (ZKSnarks/RingCT)
Experimental GUI (full featured)
Subscribe to our email newsletter for useful tips and valuable resources.
The SafeBox is the ultimate source of truth in Pascal and maintains a ledger balance of all users’ funds rather than the full ledger. Structurally, it is like a spreadsheet where each row denotes a bank account (PASA) and each column denotes a property of that account (i.e. Pascal balance, public key, etc.). The “address” of an account is simply its index within the SafeBox (with an appended checksum). Every time a new block is minted, the transactions or operations contained within that block are eventually applied to the SafeBox which results in a mutated state. The resultant hash of the mutated SafeBox must then be referenced by the subsequent block in order to qualify as the next block.
Unlike traditional UTXO-based cryptocurrencies, the blockchain in Pascal is only used to mutate the SafeBox. Whilst a Proof-of-Work blockchain is still required to facilitate Byzantine consensus (up to a checkpoint), it is not permanently required. As a result, the blockchain in Pascal is capable of being deleted without any security compromise.
Since only the ledger balance is required for consensus and not the full ledger, Pascal attains exponentially higher transaction throughput per unit of storage than UTXO-based cryptocurrencies.
Yes, the Pascal foundation is a legally registered Australian company. All details can be found in the certificate below.
The SafeBox preserves the cryptographic integrity of the full blockchain even though nodes are not required to store the full blockchain. That follows from the fact that the SafeBox contains all the block headers used to construct that SafeBox within the SafeBox itself. Each block header makes a hash commitment to the previous SafeBox state (i.e. the state of all accounts at that point in time) and also the previous block header. In this manner, the state and its evolution are preserved by using the difficulties in the block headers; the total work used to evolve that state can then be calculated. Nodes will only adopt the SafeBox with the most work.
A distinction should be made between cryptographic integrity, the proof that the SafeBox is hashed correctly from block 0, and cryptographic security, the number of blocks that need to be re-mined in an attack. The SafeBox retains the full cryptographic integrity and retains 99% of the cryptographic security of a full blockchain. The latter is due to the state-attack vector as explained in the following.
With regards to the state-attack, a distinction should be made between a double-spend and a state-attack. A double-spend refers to an attack involving majority hashpower and rolling back already accepted transactions but not hacking account balances as stored in the SafeBox. A state-attack refers to corrupting a balance and trying to cover it up by re-mining blocks in a way that other nodes cannot detect the hacked balance. With a double-spend, Pascal’s security parallels to that of a secure Proof-of-Work UTXO blockchain and is a function of hashpower. The state-attack, however, is unique to Pascal and requires an attacker to re-mine the network median history to succeed. But compared to the standard double-spend attack with hashpower majority, the state-attack is extremely difficult and unrealistic to execute.
If a state-attacker naively alters an account balance then it becomes corrupt since the tip block has an invalid SafeBox hash. If the attacker tries to re-mine that tip block faster than the rest of the honest network such that it links to its corrupted SafeBox, then the honest network can detect the tip block is invalid since they have the last 100 blocks.
If a more sophisticated state-attacker attempted to re-mine the last N blocks, and do so in a manner that it linked to his corrupted SafeBox state, then it can only fool other nodes if and only if such nodes kept less history (N-1 blocks) and the falsified SafeBox had more aggregated work than the honest SafeBox. However, this is not enough to fool the entire network since there exists archival nodes which keep the entire history, and many nodes keep large numbers of blocks. So the theoretical minimum number of blocks an attacker needs to re-mine is N=100 but in practice, it is far higher. If the network keeps a median history of 1000 blocks, then the security of the SafeBox is equivalent to a blockchain of 1000 blocks.
Formally, the SafeBox model is as secure as the median block history of the entire network with regards to the state-attack but additional security parameters as follow substantially increase the SafeBox’s security:
• The amount of difficulty required to re-mine a history grows exponentially. This means it’s exponentially harder to re-mine the last 3 blocks than it is the last 2, and so on.
• Pascal uses a 5-minute block time. Re-mining 100 blocks with a 5-minute period is far more difficult than, for example, 100 blocks with a 30-second period.
• Random Hash, an innovative ASIC & GPU resistant algorithm, serves as a powerful deterrent on hashpower monopoly.
• Since nodes require the last 100 blocks minimum, the “network median history” will never fall below 100. In practice, due to the presence of archival nodes which maintain full-history and long-running nodes which maintain large histories, the “network median history” will always be significantly larger than 100.
• Current and upcoming synchronization implementations for nodes mean that a state-attacker would need to re-mine far more than 100 blocks. For example, the default setting for nodes who opt for checkpointing instead of continuous history is to download a checkpoint per 2016 blocks or 7 days. As another example, one upcoming implementation involves downloading a checkpoint and then some preceding history; if invalid blocks are found in history, then the compromised checkpoint is eschewed altogether.
• If a state-attack succeeds, then the minority nodes that had longer histories than the state-attack rollback are immune to any balance alteration.
• If one falls to a state-attack, the worst case is that he would simply need to re-download a longer segment of the Pascal blockchain history and recover his balance(s). The state-attacker would be stuck with invalid balances unless he continues to fool others.
Technically, no blockchain data in Pascal is ever deleted even in the presence of the SafeBox. Since the SafeBox is cryptographically equivalent to a node with the entire history, Pascal nodes are not expected to contain infinite history. But for any reason(s) one may have, one could still keep all or some of the Pascal blockchain history as an option.
The SafeBox security model actually offers an advantage compared to the full blockchain model in terms of security because it places far less dependence on the full blockchain history (i.e. archival nodes). In the long term, the full blockchain model would inevitably lead to some form of centralization as well as a potential security risk. As a result, the SafeBox security model is at least on par with the full blockchain security model on the macro level.
On the micro level, the SafeBox security model is barely diminished to that of the full blockchain model. However, it is still far greater than the simple payment verification (SPV) security model. In terms of cost-benefit analysis, the SafeBox is superior to full blockchain because the SafeBox needs only “1%” of storage yet retains “99%” of security.
Thanks to the SafeBox’s design, the user would have full assurance that he is on the longest Proof-of-Work chain without needing to download the entire blockchain history – a unique innovation that offers many advantages.
Due to Pascal’s design, transactions to and from accounts can be easily audited by anyone. For many use cases, this is an excellent feature since it makes auditing, reconciliation and accounting very simple. However, Pascal is also committed to providing equally anonymizing features for those use cases where privacy is important. As a result, Pascal has a strong privacy roadmap that has already been partially rolled out.
In Pascal version 1, users could transfer Pascals privately using a PASA-exchanging approach. Instead of sending Pascals to each other’s accounts, the account itself would swap ownership. So as long as the key exchange was transmitted through secure channels, it would not be possible to trace this transaction.
Pascal’s version 3 added an in-protocol PASA and Pascal tumbling capability. Users who elect for privacy would only need to hit a checkbox, pay a marginal fee (currently set at 0.0001 Pascal), and click send. Under the hood, the wallet will automatically negotiate with other nodes for a set of obfuscating PASA/PASC swaps involving many accounts and merge these all into a single multi-operation. This process can then be chained several times offering exponentially higher security with every link, rendering the original transaction virtually impossible to decipher.
In addition, nodes will be able to earn fees by offering their latent PASC and PASA for these tumbling operations whilst simultaneously providing a rich set of decentralized PASC/PASA to participate in the tumbling. This would result in a fast, cheap, seamless and genuine anonymity for Pascal users.
The Pascal Foundation is also sponsoring R&D proposals for adding zk-SNARKs (or a similar, suitable approach) into the protocol for private balances. It is also investigating smart contract based privacy approaches.
Pascal was invented and designed by Albert Molina in May 2016. By July 2016, the the first beta version was released. On August 11th, 2016, the Pascal genesis block was generated and Albert published the source code and wallet installer on GitHub and SourceForge. On that day, Albert presented Pascal at the Bitcoin Freenode and BitcoinTalk forums.
After the initial V1 release, new developers joined the project forming what is known as the Pascal Developers. The Pascal Developers fundamentally improved the SafeBox design by providing the “missing piece of the puzzle” – the ability to make the SafeBox independently verifiable without the need for blocks, even for new nodes. This innovation was initially proposed by Herman Schoenfeld, and after discussion with Albert, was implemented in Pascal V2 by Albert.
Pascal Improvement Proposals (PIPs) are the standard way for changes to be introduced into Pascal. PIPs are intended to be the primary mechanisms for proposing new features into Pascal and documenting design decisions. Anyone can submit a PIP and all PIPs are evaluated through the PIP Workflow. Click here to see the current list of PIPs.
Development is organised via the Trello board using Agile development methodology. Pascal currently has several full-time developers including Albert Molina and Herman Schoenfeld. Sphere 10, a company directed by Herman, also allocates developers to this project from time to time. Currently there are 5 full-time developers actively working on Pascal. Various other developers have contributed to the Pascal project (web, documentation, code, etc).
Pascal, abbreviated as PASC, is the currency underlying the Pascal project. One Pascal equals 10,000 Molinas; equivalently, a Molina is 0.0001 Pascal. The Pascal account, PASA, is indivisible unlike Pascal.
Yes, the smart contract infrastructure for Pascal is currently in R&D and will be delivered in 2019.
Pascal offers powerful approaches to smart contracts due to its SafeBox model. The roadmap includes a Layer-2 overlay network for full Ethereum-style contracts. In particular, smart contracts in Pascal are isolated form the Layer-1 financial network and operate independently on Layer-2; in other words, Layer-1 will be used as a financial settlement network for Layer-2 overlay network. The characteristics of such an architecture are as follow:
• Running a smart contract engine like the Ethereum Virtual Machine (EVM) over Pascal would be possible by maintaining a side-chain pinned to a PASA account. Each PASA has infinite address space for its sub-addresses (unlike PASAs, infinite sub-addresses do not affect the SafeBox), meaning that side-chain users do not need to own a PASA.
• Since side-chains are pinned to PASAs, they are intrinsically sharded. Inter-shard communication would simply be transactions between PASAs. Gone are the complications that accompany the traditional sharding approach such as used in Ethereum.
• Layer-2 side-chains will provide very strong anonymity since funds are all pooled and keys are not used to unlock them.
• The network would not be impacted by the large volume of transactions since the natural process of checkpointing discards these transactions after 100 blocks.
• Smart contracts can be developed in any language and target any platform, since smart contract execution and consensus are separate concerns.
• Layer-2 consensus can adopt multiple forms such as Delegated Proof-of-Stake (DPoS) and Directed Acyclic Graph (DAG) depending on the side-chain’s goals.
The infinite scalability of Pascal’s Layer-1 will extend to Pascal’s Layer-2 as well. This Layer-2 architecture is designed in which the computation is separate from consensus, in effect removing any bottleneck. To be precise, the speed and scalability of Layer-2 smart contracts are fully independent of Pascal’s network. Horizontal scaling also exists in this paradigm as there is no interdependence between smart contracts and states are not managed by side-chains. One would be able to run the entire global financial system on Pascal’s smart contract platform and it would scale infinitely and securely.
Implementing this infinitely scalable smart contract platform as a Layer-2 architecture is the focus of version 5 and a whitepaper add-on for this development will be released shortly.
EMPIRICAL TRANSACTIONS PER SECOND
In a typical blockchain implementation like Bitcoin, there are three bottlenecks which determine the processing speed: • Network throughput – number of how many transactions can flood-fill network per second • Verification throughput – number of signature and consensus checks per second • Blockchain throughput – number of transactions append to the blockchain per second
The network throughput of Pascal and a traditional blockchain is similar because the net propagation speed is calculated based on the amount of bytes needed to communicate operations between nodes. The verification throughput of Pascal and a traditional blockchain are also similar. However, the blockchain throughput for Pascal is on an entirely different level thanks to Pascal’s larger block size and its differing mechanism for double spend protection.
Pascal allows for exponentially larger block sizes than current cryptocurrencies since nodes only need to keep 100 blocks or so plus the SafeBox checkpoint. This in turn increases the blockchain throughput. More details on the larger block size are given in the next section about the theoretical limit of transactions per second.
The double spend protection mechanism entails searching a given blockchain’s database (usually based on UTXO) for whether the previous transaction has been spent or not. With the SafeBox, this process is as quick as simply viewing the signer’s account state. Thanks to how the SafeBox in its entirety is stored compactly in memory, this process is almost instantaneous in Pascal. In a traditional blockchain, this process is slower because it needs to search in a database saved on disk. The difference between the time needed to search in a saved database on disk (UTXO) versus searching in memory (SafeBox) is significant, leading to a nearly instant transaction speed in Pascal.
Multithreading is used to execute processes in parallel using logical CPUs. A single low-ended CPU will process at least +300 operations per second. If 4 CPUs are available, the speed would be at least 4300 = 1,200 operations per second and would be much higher on modern CPUs. Most tests with a 4-core CPU indicate the maximum speed reaching about 1,600 transactions per second. This reflects live performance on the main net, given that the proportion of slow nodes is relatively small compared to fast nodes. 1,600 transactions per second as an empirical approximation is among the highest figures attained in any actual blockchain tests on a main net to date – if not the highest of all.
THEORETICAL TRANSACTIONS PER SECOND
The theoretical limit for transactions per second is much higher than 1,600 transactions per second and is primarily based on Pascal’s block size. For about the same amount of storage that a Bitcoin node consumes today, a Pascal could theoretically sustain a block size of 5.62 GB (compared to Bitcoin’s 1 MB block size) with a maximum blockchain throughput of 72,000 transactions per second. The maximum blockchain throughput is calculated as follows:
Maximum blockchain throughput =(Maximum block size)/(Average operation size)*(1/300)
The maximum block size of 5.62 GB is assumed and the average operation size is 262 bytes. The expression is then divided by 300, the number of seconds in a 5-minute block. This yields the 72,000 transactions per second as a theoretical limit.
It should be emphasized that Pascal’s blockchain throughput is technically unbounded. The maximum number of operations per block is not fixed and could be increased to accommodate any level of mass adoption without any undue burden on nodes because they only need the last 100 blocks and the latest SafeBox checkpoint. Such an increase in the maximum number of operations per block would lead to a higher block size and consequently a higher blockchain throughput. The maximum block size of 5.62 GB from above was arbitrarily chosen as a reasonable example of Pascal’s capacity. Concretely, storage space for the last 100 blocks is a soft constraint on Pascal’s otherwise infinite blockchain throughput.
The theoretical upper limit for Pascal’s total throughput is the minimum of the network throughput, verification throughput, and blockchain throughput. This minimum amounts to 72,000 transactions per second assuming the network and verification throughputs are infinite. The theoretical rationale for assuming network and verification throughputs as infinite is how the blockchain throughput always has a hard, albeit changeable, limit whereas other throughputs will improve constantly over time.
Pascal’s blockchain throughput from its efficient memory usage works in tandem with the nearly instant transaction speed of the SafeBox model to enable infinite scalability. It is estimated that Pascal will achieve 100,000 transactions per second as a theoretical limit (assuming a block size of 5.6 GB) with extensive core factoring, optimizations, and hardware configurations. Pascal’s total throughput is essentially only limited by Moore’s Law, storage space, and a highly decentralized architecture.
All the specifications above are for layer -1. With a layer-2 implementation, Pascal’s scalability will be enhanced even further. More information on Pascal’s layer-2 specifications will be released shortly.
PASAs need to be commoditized by the SafeBox’s design, meaning that PASAs cannot be obtained at no charge to prevent systematic abuse.
But how would one purchase a PASA using Pascal in the first place if one cannot obtain Pascal without a PASA? This is where the PASA distribution models come in the picture. There are many methods – some finished and some unfinished – to obtain a first PASA which may be free depending on the method used. Refer to the Get Started page here for more information.
Statistically speaking, there is no indication that there aren’t enough PASAs currently:
• Most PASAs in existence have 0 balance
• The average PASC balance across all PASAs is approximately 20 at the moment
• There are more than a million PASA accounts and less than 5% are in use
Some other point to consider regarding the PASA supply:
• There could come a time when the number of new users is rapidly growing; the rate would need to be sustained at one new user per minute for a significant amount of time to exhaust all the existing available and/or empty PASAs.
• A significant number of Pascal users are willing to keep their PASC on exchanges and therefore don’t require a PASA.
• If a PASA is inactive for 10 years, it would be recycled and thus help in replenishing the PASA supply.
• The total maximum number of possible PASAs in existence is 4.2 billion, and this could easily be increased if needed.
• A Layer-2 application for Pascal as part of V5 is in the works that would secure multiple pseudo-PASA accounts via a PASA - similar to a proof-of-stake paradigm - and therefore removing the need to own a PASA as an alternative option.
In both the short- and long-term horizons, the supply of PASA is not a problem.
As explained in the above, the supply of PASA is relatively abundant and so the PASA price is likely to remain inexpensive.
If the PASC price increases due to a surge of interest in Pascal, it is conceivable that there will be much more demand on the buy side for PASAs. This would translate in many more users trying to sell their dormant, inactive PASAs. This would cause a sell pressure and the PASA price may lower.
Conversely, if the price of PASA does increase then there are many available community-driven, decentralised options via PIPs to keep the PASA price low, including but not limited to:
• Increasing the supply of PASAs mined per PASC (currently set at 1 PASA per 5 PASC)
• Issuing accounts per block in accordance with Moore’s Law
• Dynamic and instant account creation using new and yet-to-be implemented Create Account & Destroy Account operations
• One-time issuance of millions of accounts to any entities (Pascal Foundation, freepasa.org, etc.) for any kind of distribution methodologies
Also, please note that there are many ways - either currently or planned in the future - to acquire a PASA conveniently for free regardless of the PASA price. Refer to https://www.pascalcoin.org/get_started and https://www.pascalcoin.org/content/wallet_pascal_pasa_faucet. As two examples, one would not need to own a PASA in the near future with layer-2 development and one would be able to acquire a free PASA simply with a single SMS message.
While PASAs need to be commoditized to a degree as part of SafeBox's architecture, they will always remain affordable at a very inexpensive price as well as continually become easier to acquire for free over time as more acquisition methods are implemented.
After the exchange of public keys; the new owner (with the private key) obtains full rights over the PASA, the public key and private key held by the previous owner becomes invalid as regards the sold PASA. The new owner can now use the PASA for transactions on the Pascal blockchain and can also sell-on this account or give it out when he/she wishes using the same procedure.
When you download a Pascal wallet application and create a private key profile, the private key is associated with a public key; while your private key is unique and only known to you (unless you decide to share it with others), the public key is also unique but sharing it with others doesn’t pose any negative security implication. your public key can be freely shared with others
When a miner is rewarded with a PASA; he owns the public key to the PASA, the public key can be readily changed at anytime without knowing the new owner’s private key, however only the use with the new private key has control over this account after the exchange.
Think of this process as obtaining a bank account, to obtain a bank account number, the client fills his public details in the account creation form, this enables the bank to assign a unique account number to the client, the client has full ownership rights to this new account. However, in contrast to the bank account, the PASA is completely decentralized and is not under the influence of any third party or the original owner
Just like the phrase rightly suggests, Pascal Accounts (PASA) which have stayed dormant for a period of four years are automatically recovered and returned to the mining pool. Miners will be able to earn this recovered account (including the account balance) as part of the Mining reward. Dormant accounts by definition here includes accounts which haven't performed any (outgoing) transaction over the specified period. While this may seem odd, it ensures continued use of the blockchain as users are prompted to use their Pascal account more constantly. LEARN MORE
Operations in Pascal are the equivalent to “transactions” in traditional cryptocurrencies. The difference is that Pascal has many different types of operations, not just for transferring funds. For example, there are operations to change an account's key or to change an account's name. As a result, an operation in Pascal should be considered as an abstract and generalised form of a cryptocurrency “transaction”.
A “Transaction” in Pascal is a type of operation that transfers funds between accounts.
Pascal currently supports the following operations:
Transaction: moves funds from one account to another
Change Account Key: changes ownership of an account
List Account For Sale: lists an account for public or private sale
Delist Account: delists an account from sale
Buy Account: purchases and settles an account listed for sale
Change Info: changes an account's name and type
OP DATA: envelope for embedding layer-2 protocols (that can carry funds)
Recover Account: reassigns an inactive account to a new owner (account must not have made an operation for at least 4 years)
When operations are sent, they are visible to all nodes after a few seconds. However, they live in the “Pending Operations” pool until a miner mints them in a block. After 5 minutes (average), a block will be minted and will likely contain all the Pending Operations. As with other blockchain-based cryptocurrencies, it is best to wait a reasonable number of block confirmations before considering the payment as cleared. The more block confirmations that an operation receives, the less likely it is ever to be rolled back.
For large transfers, waiting for 2-4 confirmations is acceptable. For small micro-transactions, many accept 0-confirmation transaction since they are still quite safe - good enough for coffee. In the future, there will be a Double-Spend-Detection-Service to further verify 0-confirmation transactions for reliability.
Pascal can be purchased from cryptocurrency exchanges using Bitcoin and/or other major coins.
See next question for list of exchanges.
Pascal supports the full 3rd party integration capability including offline coldwallet operation signing.
For a simplified integration approach see read this PDF.
Check out the mining guide below as well as visit our Discord channels #mining and/or #rhminer to get started.
Pascal uses Proof-of-Work (PoW).
The SafeBox model does not work with Proof-of-Stake (PoS) since stake-proofs cannot be aggregated to secure the SafeBox. However, Proof-of-Stake will also be incorporated in Pascal's layer-2 development in the near future.
Pascal uses a 5 minute block time. However, 0-confirmation transactions are much more reliable than in other cryptocurrencies. Additionally, once the double-spend-detection-service is rolled out, merchants will be able to accept 0-confirmation transactions with a high degree of confidence. Such transactions would be suitable for small purchases like coffee.
For transactions of significant value, we recommend a reasonable number of confirmations before considering a payment as cleared.
Source code is maintained in GitHub.
PascalCoin offers a JSON RPC API available on both the Daemon and the GUI.
There is a full C# implementation of PascalCoin being developed by Sphere 10 software called NPascalCoin. It currently supports the JSON-RPC API with plans for network protocol.
The wallet supports English so far, but we are working on translations as well. Reach out to us if you’d like to help with translations.