Pirichain Whitepaper
🌍 Pirichain🔮 Explorer🧰 API
  • 👋What is Pirichain?
  • Overview
    • 🔮Upcoming Projects
  • PIRICHAIN INFRASTRUCTURE
    • 🛤️Pirichain Infrastructure
      • 🅱️1.1. Pirichain specific block fields
      • ⏩1.2. Pirichain-specific transaction fields
      • 📒1.3. Pirichain Wallet Structure
        • 👤Personel Wallet
        • 💼Business Wallets
      • 👉1.4. Creation of Pirichain Transaction
      • 📎1.5. A New Concept in Blockchains! Adding Data to the Blockchain
      • 💠1.6. Pirichain's Web Server Services Structure
      • 🤝1.7. Consensus at Pirichain
  • PIRICHAIN SMART SCENARIO
    • 💡Pirichain Smart Scenario
      • 🌀2.1. Pirichain Smart Scenario Virtual Machine
        • ⚗️2.1.1. Pirichain Example Smart Scenarios
          • 🩺2.1.1.1. A Scenario on Health
          • 📦2.1.1.2. A Scenario on Inventory
        • 🎓2.1.2. Scenario of calculating the semester average with course grades and coding example
  • PIRICHAIN PLATFORMS
    • 🖥️3.1. Pirichain Desktop Wallet & Database Bridging Application (Wallet & DataBridge Application)
  • PIRICHAIN TRANSACTION TYPES
    • ⛓️4. Pirichain Transaction Types
  • PIRICHAIN COMMISSION
    • 🔥5. Pirichain Commission
  • PIRICHAIN REWARD DISTRIBUTION
    • 🎁6. Pirichain Reward Distribution
  • PIRI Coin Holders
    • 👥PIRI Tokenomics
  • 📍Pirichain Projected Roadmap
  • ⬆️Updates
    • 🚀New Fee Mechanism in Pirichain
  • REFERENCES
  • 🌎Pirichain Showcase
  • 🔎Pirichain Explorer
  • 🌐Pirichain Scanner
  • ✒️Pirichain Master Thesis
Powered by GitBook
On this page

Was this helpful?

  1. PIRICHAIN SMART SCENARIO
  2. Pirichain Smart Scenario

2.1. Pirichain Smart Scenario Virtual Machine

PreviousPirichain Smart ScenarioNext2.1.1. Pirichain Example Smart Scenarios

Last updated 2 years ago

Was this helpful?

Commands to be included in the system are made ready to be run in the system after lexer design, syntax and semantic controls by Piricihain Virtual Machine. In addition, malicious (devil codes) codes for locking the system from the logical side are detected (if found, they are reported to the Pirichain system) and bad codes are extracted.

Each scenario code written on the system is given an execution time of maximum 50 seconds. Every process that has not finished running (throwing runtime timeout error) within this time scale is canceled. Each canceled scenario is administratively reported by the server. A certain number of scenarios that tire the system (receiving a timeout error) are removed without notice. Addresses that frequently repeat the same situation in the system are blocked regardless of the balances of the assets in them. These addresses cannot operate in the system and cannot access the system. An example of cross-scenario work is briefly shown in Figure 2.3. The data sent by the user with a certain balance in the scenario is sent to Scenario B. Before Scenario B is run, “Scenario Execution Authorization” is checked. Otherwise, the Program is terminated. If available, it is sent to Scenario C and Scenario C is run. The program is terminated without running any scenario for the user with no balance.

In Figure 2.4, a structure constructed between scenarios in detail has been created. As seen in the structure, it shows that the data requested from the school and the Ministry of Education of a student applying to X university is run on the scenario of X university.

💡
🌀
Figure 2.3: Working example between scenarios
Figure 2.4: Detailed operational view of scenarios