LogoLogo
Exchange
Exchange
  • Introducing: LX
  • Main Features
    • Social Features
  • Reliability
  • High Liquidity
  • High Performance
  • Simple Trading
  • Diversity
  • Interoperability/Bridge
  • User Support
  • Transparency
  • Security
  • The Problem
    • Negative Consequences of Centralization
  • The Solution
    • Security Solutions as a Decentralized Exchange
  • LX: A Decentralized Social Trading Platform
    • Lux Exchange DAO
  • Decentralized Application
  • User Experience
    • Easy to use
  • Accounts, Wallets, and Keys
  • Authentication
  • Features
    • Hardware Wallets
  • Portfolios
  • Social Trading
  • People Based Portfolios
  • Copy Swaps
  • Trading Charts
  • Indicator Alarm Manager
  • Smart Search
  • Watchlist
  • Community Support
    • Decentralized community service
  • Rewarded Content Production/Trading Bots
  • Token Curated Customer Service
  • LX Architecture
    • LX Architecture Comparison
  • eToro
  • EtherDelta
  • 0x Protocol
  • LX
  • Lux Protocol
    • Lux as a Distributed Autonomous Organization (DAO)
  • Governance
  • Lux Consensus
  • Terminology
  • Election Triggers
  • Attacks
    • Tragedy of Commons
  • Collusion
  • Censorship
  • ASIC Attacks
  • Long Range Attacks
  • Treasury and Bounty
    • Budgeting
  • Bounty
  • Lux Tokenomics
  • Decentralized Liquidity Pool (DLP)
  • Market Maker Fees
  • LX C++ Application Programming Interface (API)
  • Permission Mapping
  • Permission Evaluation Applied to Copy Trading
  • Parallel Permission Evaluation
  • LX Key Capabilities
  • Atomic Swaps
  • Facilitating Liquidity
  • Exchange Traded Funds
  • Crypto-asset Custody for Gateways
  • Cold Wallet
  • Smart coins
  • Crypto-asset Volatility
  • Gold as Collateral
  • Incentives
  • Interest Rate
  • Development Roadmap
  • LUX Constitution and Ricardian Contracts
  • Lux Protocol
  • DEX Core Platform
  • DApp UI/UX
  • Hardware Wallet Integration
  • Quality Assurance
Powered by GitBook
On this page

Was this helpful?

Parallel Permission Evaluation

The permission evaluation process is read-only and changes to permissions made by transactions do not take effect until the end of a block. This means that all keys and permission evaluation for all transactions can be executed in parallel. Furthermore, this means that a rapid validation of permission is possible without starting costly application logic that would have to be rolled back. Lastly, it means that transaction permissions can be evaluated as pending transactions and do not need to be re-evaluated as they are applied.

All things considered, permission verification represents a significant percentage of the computation required to validate transactions. Making this a read-only and trivially parallelizable process enables a dramatic increase in performance.

When replaying the blockchain to regenerate the deterministic state from the log of actions, there is no need to evaluate the permissions again. The fact that a transaction is included in a known good block is sufficient to skip this step. This dramatically reduces the computational load associated with replaying an ever growing blockchain.

PreviousPermission Evaluation Applied to Copy TradingNextLX Key Capabilities

Last updated 2 years ago

Was this helpful?