Checkturio is SaaS solution for efficient End-to-End fleet asset management powered by AI: ✔ Real-time damage and vehicle status reports ✔ Digital status documentation ✔ Damage allocation ✔ AI-assisted damage detection ✔ Customized checklist builder Start checking today. More info: www.checktur.io IMPRINT Checktur.io GmbH Wolliner Straße 18 10435 Berlin Germany hello@checktur.io Management Dr. Luisa Müller-Wittmann Agnieszka Michalik Local court / Commercial register Registered at the local court Amtsgericht Berlin-Charlottenburg HRB 246406

Checktur

Creating Production Grade Microservices with Go and gRPC

A Better Implementation of Enhanced Repository Pattern in .NET C#

When you start to understand more about different Blockchain technologies and want to start developing your own applications, if you don't have experience with some technologies (such as Node, Rust, etc.) it will be a little more difficult than you thought to enter the Web3 world. Fortunately, now you can use any programming language and connect to different Blockchains through APIs, thanks to . And in this article, we will do just that, by creating a wallet with the network. Tatum Algorand What is Tatum? is a service and framework that offers access to different blockchain networks through APIs, SDK, plugins (for WordPress), and even through a console interface. Tatum Its advantage is that it abstracts the complexities involved in working with a particular blockchain (with its own SDK), you can even work on a multi-chain project with very few changes. And all this, free at first (with quotas of requests per second). What is Algorand? Algorand is a blockchain network that is defined as " " ( ), designed in high-speed transaction processing and high-level smart contracts for decentralized finance ( ). Algorand's token is . Pure Proof of Stake PPoS DeFi ALGO The use of PPoS is framed in achieving block production speed measured in a few seconds, which would allow a high scalability of the network, thus serving thousands of users concurrently, with very short waiting times and, above all, with Very low commission costs. Algorand is capable of handling about 2 thousand transactions per second without problems in its current network state. One of the main features of Algorand is that any user who is online and holds ALGO tokens can participate in the PPoS system. In other words, PPoS eliminates the barrier that PoS ( ) imposes on hard staking, where it is necessary to retain a certain number of tokens to participate in the process of selecting, generating and validating transactions and blocks. Proof of Stake Creating a wallet A wallet allows you to have control over your assets and tokens for one or several blockchain networks, and it is precisely what I wanted. I didn't trust much in the ones I found, and since I wanted to learn just like you, I created it only with Tatum, HTML, Javascript with Jquery and CSS, which I called AlgoNaut. You can test it . It works in Algorand testnet. here What can you do? In AlgoNaut you can: Create a new address (with your public and private key). Authenticate with your private key. View your ALGO balance. Transfer SOMETHING to another account. Check if an address is valid (a Tatum-specific functionality). How to use it? First, create your Tatum account and get an API key (you can select whether it will be a mainnet or testnet one). Next, you must build the entire frontend of your app (a page to create your account, another to authenticate and finally one with your account details (balance and transfer form). You can fork AlgoNaut from this . repository Next, you need to jquery the Tatum API with the respective endpoint (when you create your key you will know the endpoint) and create the methods to get the balance, create an account, verify an address and make a transfer. In the repository, you can check out the file inside the JS folder. main.js } addresses = [] } } } } } }, }; checkBalance(); });
} }
      }; saveAddressInStorage(response.address, response.secret);
      });
} } }
      }; saveAddressInStorage(response, privateKey);
        confirmKeySaved(); });
    } }
} }
      }; });
} }
      }; });
} }
      }; });
} }
      }; } } });
} } ); checkBalance(); } generateWallet()}); generateWalletFromPrivateKey()}); confirmKeySaved()}); checkAddress()}); logout()}); sendTransaction()});
    
}
    
); const api = "API_TATUM" ; function saveAddressInStorage ( address, secret ) { var addresses = JSON .parse( localStorage .getItem( "addresses" )); if (addresses != null ) { addresses.push({ address :address, key : secret}); else { addresses.push({ address :address, key : secret}); localStorage .setItem( "addresses" , JSON .stringify(addresses)); function getFirstAddress ( ) { var addresses = JSON .parse( localStorage .getItem( "addresses" )); return addresses[ 0 ]; function sendTransaction ( ) { var address = getFirstAddress(); var recipient = $( '#trx_address' ).val(); if (recipient == '' ) { $( '#errorTrx' ).css( "display" , "block" ); $( '#errorTrx' ).text( "Recipient is invalid" ); return ; var memo = $( '#trx_memo' ).val(); var amount = $( '#trx_amount' ).val(); if (amount == '' ) { $( '#errorTrx' ).css( "display" , "block" ); $( '#errorTrx' ).text( "Amount is invalid" ); return ; const settings = { "async" : true , "crossDomain" : true , "url" : "https://api-us-west1.tatum.io/v3/algorand/transaction" , "method" : "POST" , "headers" : { "content-type" : "application/json" , "x-api-key" : api "processData" : false , "data" : "{\"from\":\"" +address.address+ "\",\"to\":\"" +recipient+ "\",\"fee\":\"0.001\",\"amount\":\"" +amount+ "\",\"note\":\"" +memo+ "\",\"fromPrivateKey\":\"" +address.key+ "\"}" $.ajax(settings).done( function ( response ) { $( '#errorTrx' ).css( "display" , "none" ); $( '#errorTrx2' ).css( "display" , "block" ); $( '#errorTrx2' ).text( 'The transaction is valid and successfully execute with id ' +response); console .log(response); }).fail( function ( response ) { $( '#errorTrx' ).css( "display" , "block" ); $( '#errorTrx2' ).css( "display" , "none" ); $( '#errorTrx' ).text( 'There was an error with your transaction. Check the form.' ); response.responseJSON.data[ 0 ]. console .log(response); function generateWallet ( ) { const mnemotic = $( '#mnemoticWallet' ).val(); const settings = { "async" : true , "crossDomain" : true , "url" : mnemotic !== "" ? "https://api-us-west1.tatum.io/v3/algorand/wallet?mnemonic=" +mnemotic : "https://api-us-west1.tatum.io/v3/algorand/wallet" , "method" : "GET" , "headers" : { "x-api-key" : api $.ajax(settings).done( function ( response ) { console .log(response); $( '#new_address_generated' ).show(); $( '#new_wallet_address' ).text(response.address); $( '#new_wallet_secret' ).text(response.secret); function confirmKeySaved ( ) { localStorage .authenticated = "true" ; location.href = 'index.html' ; function generateWalletFromPrivateKey ( ) { const privateKey = $( '#pvKeyValue' ).val(); if (privateKey != '' ) { const settings = { "async" : true , "crossDomain" : true , "url" : "https://api-us-west1.tatum.io/v3/algorand/address/" +privateKey, "method" : "GET" , "headers" : { "x-api-key" : api $.ajax(settings).done( function ( response ) { }).fail( function ( response ) { $( '#errorLogin' ).css( "display" , "block" ); $( '#errorLogin' ).text( 'The private key is not valid.' ); else { $( '#errorLogin' ).css( "display" , "block" ); $( '#errorLogin' ).text( 'The private key is not valid.' ); function checkBalance ( ) { const publicAddress = getFirstAddress().address; const settings = { "async" : true , "crossDomain" : true , "url" : "https://api-us-west1.tatum.io/v3/algorand/account/balance/" +publicAddress, "method" : "GET" , "headers" : { "x-api-key" : api $.ajax(settings).done( function ( response ) { $( '.view_balance_address' ).text(response); function checkCurrentBlock ( ) { const settings = { "async" : true , "crossDomain" : true , "url" : "https://api-us-west1.tatum.io/v3/algorand/block/current" , "method" : "GET" , "headers" : { "x-api-key" : api $.ajax(settings).done( function ( response ) { $( '.view_block_number' ).text(response); console .log(response); function getBlockData ( blockNumber ) { const settings = { "async" : true , "crossDomain" : true , "url" : "https://api-us-west1.tatum.io/v3/algorand/block/" +blockNumber, "method" : "GET" , "headers" : { "x-api-key" : api $.ajax(settings).done( function ( response ) { console .log(response); function checkAddress ( ) { const address = $( '#verify_address' ).val(); const settings = { "async" : true , "crossDomain" : true , "url" : "https://api-us-west1.tatum.io/v3/security/address/" +address, "method" : "GET" , "headers" : { "x-api-key" : api $( '#is_valid_address' ).css( 'display' , "block" ); $.ajax(settings).done( function ( response ) { if (response.status == 'valid' ) { $( '#is_valid_address' ).text( 'The address ' +address+ " is valid" ); else { $( '#is_valid_address' ).text( 'The address ' +address+ " is not valid" ); console .log(response); }).fail( function ( response ) { $( '#is_valid_address' ).text( 'The address ' +address+ " is not valid" ); console .log(response); function logout ( ) { localStorage .clear(); location.href = 'login.html' ; setInterval ( checkCurrentBlock(), 30000 $( function ( ) { if ( localStorage .authenticated != null ) { var address = getFirstAddress().address; $( '.current_account' ).qrcode(address); $( '.current_account_text' ).text(address); $( '#generateWalletButton' ).click( function ( ) { $( '#generateWalletPrivKeyButton' ).click( function ( ) { $( '#confirmKeySavedButton' ).click( function ( ) { $( '#verifyAddressButton' ).click( function ( ) { $( '#btnLogout' ).click( function ( ) { $( '#sendTrxButton' ).click( function ( ) { As you can see, you will need your API key on line 1 of the file to be able to make the calls.
 Also, the private key and other data are stored in the localstorage of the machine (it is not shared with anyone else). When you already have your API in the file, just open the index.html file and your wallet will be available on your machine (as in my case, you can publish it directly on GitHub). As you can see, without the need to be an expert in Javascript or blockchain, you can have your own application in just a few steps thanks to Tatum. You can set the wallet to constantly load the current Algorand block, it only shows up on page load and doesn't update until you refresh the page. You can also set it to be multi-chain. It's your turn Now is your time to participate in Web3 with your own applications, whether or not you are an expert in programming, you can participate without problems thanks to technologies such as Tatum. You have even seen a wallet, but the possibilities for development and projects are endless.

AlgoNaut - an Algorand wallet with Tatum

This article is a practical guide on making a simple Node.js server that will receive BTC transactions as a Webhook and detect if a transaction contains more than $2Bln worth of BTC transfer. It doesn’t necessarily mean that someone cashes out or buys that match of BTC once; we don’t know, BUT if that kind of amount gets transferred a lot during the week, then we can assume that the overall network is quite active. It would be possible to make some investment design based on that information. Of course, this is not a financial or investment guide, and it is pure curiosity as a software engineer 🧐 Tools We Need First of all, we need some source for our data, which will give us the latest block and transactions confirmed by the blockchain network. There are not many services that we can use to monitor confirmed blocks for free, so seems the best choice here because they even have Webhook events, which is ideal for us. Blockpulsar.com After registering with Blockpulsar, now we can set a on every new confirmed transaction in the Bitcoin network. They will send us a Transaction object every time there is a new confirmed transaction, from where we can get a value of how much BTC it contains. Webhook event Based on types documented in we will get the following JSON Object for each Transaction Webhook callback. We need a transaction id, transaction inputs, outputs, and their addresses with BTC amount. Blockpulsar’s docs {
  "txid": "fff2525b8931402dd09222c50775608f75787bd2b87e56995a7bdd30f79702c4",
  ...
  ...
  "vin": [
    {
      ...
      "value": 3.54312,
      "addresses": [
        "1JqBybe5nWtENrHnMyafbSXXtTh5Uv5Qab"
      ],
      ...
    }
  ],
  "vout": [
    {
      "value": 5.56,
      ...
      ...
      "script_pub_key": {
        ...
        ...
        "addresses": [
          "1JqDybm2nWTENrHvMyafbSXXtTk5Uv5QAn"
        ]
      }
    }
  ],
  ...
  ...
} This object structure seems pretty straightforward. We have to make some Node.js, Golang, or any other language-based HTTP Server, which will handle a Transaction JSON Request and parse it accordingly. I’m choosing the Node.js server because that’s the most widespread technology for this kind of light server development. Handling New Transactions with Node.js To get started, we need a simple Express.js server to receive POST requests from Blockpulsar’s Webhook events. Because our server’s URL must be public, we have to make some “security“ measures to ensure that incoming requests are sent only from Blockpulsar servers. It sounds tricky, but in practice, almost all Webhook-based callbacks use the same technique. We either have to provide a unique Query parameter to check or check request headers. It looks like in practice with a basic Express.js setup and Body Parser for having JSON POST body available as an object. const express = require('express');
const bodyParser = require('body-parser');

const FIXED_QUERY_TOKEN = "some-long-token-for-security";
const app = express();
app.use(bodyParser.json());

app.post('/transaction', (req, res) => {
  if (req.query.token !== FIXED_QUERY_TOKEN) {
    return res.send(401);
  }
  const transaction = req.body;
  console.log(transaction);
  res.json({});
});

app.listen(process.env.PORT ?? 3000); Now we have a simple Express.js server to handle a transaction object as an HTTP POST request and make sure that the upcoming request contains our unique query parameter because our API is going to be a public URL. ?token=<our-token> Setting Webhook URL There are many ways to deploy this as a public URL-based API server for free because we do not match here. I’ve chosen to deploy this to Heroku, which is quite good as a free option, and it is pretty simple to do—not going to explain how Heroku deployment works. You can find pretty much anything on that topic. I’ll assume that you know how to do it 😀 After a simple deployment process to Heroku, I got a public URL for my Express.js server, and I can have my transaction tracking endpoint available as the following URL https://bitcoin-transaction-tracking.herokuapp.com/transaction?token=some-long-token-for-security Now is the time to set this URL as a Blockpulsar Webhook callback as a Bitcoin transaction event callback URL. To do that, we have to call a simple API, which you can do over Postman or just a light HTTP client directly embedded to your VSCode or Webstorm, whichever you want, but . the request looks like this POST https://api.blockpulsar.com/hooks/webhook
x-api-key: <your api key>
x-api-secret: <your api secret>
Content-Type: application/json

{
  "url": "https://bitcoin-transaction-tracking.herokuapp.com/transaction?token=some-long-token-for-security",
  "subscriptions": [
    {
      "type": "TRANSACTION",
      "currency": "BTC"
    }
  ]
} With this API call to Blockpulsar, we tell that “Send an HTTP POST request to our given URL, whenever there is a new transaction confirmed in Bitcoin Blockchain. “ It might take a few minutes to start receiving new transactions because the average block mining time is around 8 minutes, which sometimes takes even 30 minutes, but after some time, you will begin seeing a blast of JSON objects in your server logs from . All you have to do now is parse the coming transaction and find if more than 5000 BTC is being transferred or not. console.log(transaction) The Transaction Contains More than 5000 BTC 🚨 Each Bitcoin blockchain transaction contains fields that represent sending and receiving amounts to specific addresses. We don’t know for sure which specific address sends to whom, but if there is only one and one then it is clear which address sends and which one is receiving. vin, vout vin vout To check an actual amount, we have to go over all and arrays and check if we have a transfer of more than 5000 BTC at once. transaction.vin transaction.vout function checkTransferAmount(transaction, amount = 5000) {
  const findModeThanAmount = (vinOrVout) => vinOrVout.find(
    ({ value }) => value >= amount
  );
  return !!findModeThanAmount(transaction.vin) || !!findModeThanAmount(transaction.vout);
} This conditional aggregation is a straightforward example of finding if there is a spend or receiving amount more than the given amount (default 5000 BTC). We have to call this function every time we get a transaction to log only transaction ids that contain more than 5000 BTC input or output. const express = require('express');
const bodyParser = require('body-parser');

const FIXED_QUERY_TOKEN = "some-long-token-for-security";
const app = express();
app.use(bodyParser.json());

app.post('/transaction', (req, res) => {
  if (req.query.token !== FIXED_QUERY_TOKEN) {
    return res.send(401);
  }
  const transaction = req.body;
  if (checkTransferAmount(transaction)) {
    console.log('MORE THAN 5000 BTC -> ', transaction.id);
  }
  res.json({});
});

app.listen(process.env.PORT ?? 3000);

function checkTransferAmount(transaction, amount = 5000) {
  const findModeThanAmount = (vinOrVout) => vinOrVout.find(
    ({ value }) => value >= amount
  );
  return !!findModeThanAmount(transaction.vin) || !!findModeThanAmount(transaction.vout);
} Now we will get an output to our Server logs similar to this one MORE THAN 5000 BTC -> fff2525b8931402dd09222c50775608f75787bd2b87e56995a7bdd30f79702c4 How to Use this Information? You now have a tool that can trigger some chatbot or even automation API for your trading bot on a specific hook of finding if the newly confirmed transaction matches your condition. One of the best use-cases is making a Twitter bot similar to Wealth Alert, where you can tweet BTC Addresses that are making transactions with more than configured amounts. Let me know what kind of use case you have. I would be happy to assist 🤞 I’m a CTO at Blockpulsar Inc. and with this article wanted to showcase use-cases for our event-driven blockchain API. Disclaimer:

How to Track Bitcoin Transactions Worth $2 Billion or More

Tree - AST Crushes JSON, XML, YAML, TOML, etc

The Power of Campaign Management in Driving Business Objectives and Checkout Success

This paper is available on arxiv under CC 4.0 license.
Authors:
(1) Falke B. Ø. Carlsen, Department of Computer Science, Aalborg University, Denmark & falkeboc@cs.aau.dk;
(2) Lars Bo P. Frydenskov, Department of Computer Science, Aalborg University, Denmark & larsbopark@gmail.com;
(3) Nicolaj Ø. Jensen, Department of Computer Science, Aalborg University, Denmark & noje@cs.aau.dk;
(4) Jener Rasmussen, jener@jener.dk;
(5) Mathias M. Sørensen, mathiasmehlsoerensen@gmail.com;
(6) Asger G. Weirsøe, asger@weircon.dk;
(7) Mathias C. Jensen, Department of Computer Science, Aalborg University, Denmark & mcje@cs.aau.dk;
(8) Kim G. Larsen, Department of Computer Science, Aalborg University, Denmark & kgl@cs.aau.dk. Table of Links Introduction Definitions Model Checking Tool Overview Evaluation Conclusion and References 4 Tool Overview CGAAL (https://github.com/d702e20/CGAAL) is written in Rust and consists of a command-line interface and a verification engine. The primary feature of CGAAL is the verification of ATL properties for CGSs. Verification is either done with a global algorithm or local algorithm, both of which are described in Section 3. If requested, a partial strategy witness can also be computed, which instructs how the given players must play to satisfy the given property. Another feature converts the model into dot graph format such that it can be visually rendered with Graphviz.[2] To model concurrent game structures for CGAAL, we designed a declarative Language for Concurrent Game Structure, called LCGS. In LCGS a CGS is defined with a series of declarations such that it is possible to find the successors of any state from the declarations alone. The language acts as an abstract representation of the CGS and allows us to save memory at the small cost of having to evaluate the expressions of declarations whenever successors are explored. The syntax of the language is inspired by PRISM-lang [11] used by the PRISM model checker to model stochastic multi-player games with rewards. However, LCGS differs in multiple ways. For instance, LCGS has player templates instead of modules, and templates have no effect unless there exists an instance of it. Additionally, synchronisations affecting the internal state of a player are much easier to declare. Example Use As an example, we want to check if a cowboy can guarantee to stay alive in a three way Mexican standoff. The standoff is simulated in rounds and in each round a cowboy can choose to wait, shoot the cowboy to the right, or shoot the cowboy to the left. If a cowboy is hit by two bullets, he dies. We model this scenario in Listing 1. The cowboy template is declared on lines 3-17. Herein, on line 6, we define that each cowboy can be hit by two bullets before being incapacitated, but we make this number a constant on line 1 so it is easy to change. Each cowboy has their own health variable and the combination of the values of these variables makes up a state. Line 7 defines how the health of a cowboy is updated in each transition. The value of opp_right.shoot_left and opp_left.shoot_right are 1 if this cowboy was shot by the given opponent to the right or left, respectively, otherwise 0. On line 10 we define a label called alive, which is a proposition that is true if the cowboy has more than zero health. Lines 13-15 define the actions of the cowboy template, and the expression to the right of the name is a condition defining in which states the action is available. As can be seen, a cowboy can always wait, but only shoot if they and their target are alive. Lastly, we declare three instances of the cowboy template on lines 20-22. We define the right and left opponent in the relabelling function after the name of the template. Any identifier in a template can be relabelled to another expression as long as the result is syntactically and semantically correct. The ATL formula ⟪billy⟫□billy.alive is satisfied if the cowboy billy has a strategy to stay alive. We can now run CGAAL with the following command: ./cgaal solver -m standoff.lcgs -f billy-can-stay-alive.atl, and CGAAL will tell us that the property is not satisfied. Billy has no strategy that can guarantee his survival. [2] Graphviz: https://graphviz.org/ This paper is available on Arxiv under CC 4.0 license. This paper is available on arxiv under CC 4.0 license. Authors: (1) Falke B. Ø. Carlsen, Department of Computer Science, Aalborg University, Denmark & falkeboc@cs.aau.dk; (2) Lars Bo P. Frydenskov, Department of Computer Science, Aalborg University, Denmark & larsbopark@gmail.com; (3) Nicolaj Ø. Jensen, Department of Computer Science, Aalborg University, Denmark & noje@cs.aau.dk; (4) Jener Rasmussen, jener@jener.dk; (5) Mathias M. Sørensen, mathiasmehlsoerensen@gmail.com; (6) Asger G. Weirsøe, asger@weircon.dk; (7) Mathias C. Jensen, Department of Computer Science, Aalborg University, Denmark & mcje@cs.aau.dk; (8) Kim G. Larsen, Department of Computer Science, Aalborg University, Denmark & kgl@cs.aau.dk. This paper is available on arxiv under CC 4.0 license. Authors: Authors: (1) Falke B. Ø. Carlsen, Department of Computer Science, Aalborg University, Denmark & falkeboc@cs.aau.dk; (2) Lars Bo P. Frydenskov, Department of Computer Science, Aalborg University, Denmark & larsbopark@gmail.com; (3) Nicolaj Ø. Jensen, Department of Computer Science, Aalborg University, Denmark & noje@cs.aau.dk; (4) Jener Rasmussen, jener@jener.dk; (5) Mathias M. Sørensen, mathiasmehlsoerensen@gmail.com; (6) Asger G. Weirsøe, asger@weircon.dk; (7) Mathias C. Jensen, Department of Computer Science, Aalborg University, Denmark & mcje@cs.aau.dk; (8) Kim G. Larsen, Department of Computer Science, Aalborg University, Denmark & kgl@cs.aau.dk. Table of Links Introduction Introduction Definitions Definitions Model Checking Model Checking Tool Overview Tool Overview Evaluation Evaluation Conclusion and References Conclusion and References 4 Tool Overview CGAAL (https://github.com/d702e20/CGAAL) is written in Rust and consists of a command-line interface and a verification engine. The primary feature of CGAAL is the verification of ATL properties for CGSs. Verification is either done with a global algorithm or local algorithm, both of which are described in Section 3. If requested, a partial strategy witness can also be computed, which instructs how the given players must play to satisfy the given property. Another feature converts the model into dot graph format such that it can be visually rendered with Graphviz.[2] To model concurrent game structures for CGAAL, we designed a declarative Language for Concurrent Game Structure, called LCGS. In LCGS a CGS is defined with a series of declarations such that it is possible to find the successors of any state from the declarations alone. The language acts as an abstract representation of the CGS and allows us to save memory at the small cost of having to evaluate the expressions of declarations whenever successors are explored. The syntax of the language is inspired by PRISM-lang [11] used by the PRISM model checker to model stochastic multi-player games with rewards. However, LCGS differs in multiple ways. For instance, LCGS has player templates instead of modules, and templates have no effect unless there exists an instance of it. Additionally, synchronisations affecting the internal state of a player are much easier to declare. Example Use As an example, we want to check if a cowboy can guarantee to stay alive in a three way Mexican standoff. The standoff is simulated in rounds and in each round a cowboy can choose to wait, shoot the cowboy to the right, or shoot the cowboy to the left. If a cowboy is hit by two bullets, he dies. Example Use We model this scenario in Listing 1. The cowboy template is declared on lines 3-17. Herein, on line 6, we define that each cowboy can be hit by two bullets before being incapacitated, but we make this number a constant on line 1 so it is easy to change. Each cowboy has their own health variable and the combination of the values of these variables makes up a state. Line 7 defines how the health of a cowboy is updated in each transition. The value of opp_right.shoot_left and opp_left.shoot_right are 1 if this cowboy was shot by the given opponent to the right or left, respectively, otherwise 0. On line 10 we define a label called alive, which is a proposition that is true if the cowboy has more than zero health. Lines 13-15 define the actions of the cowboy template, and the expression to the right of the name is a condition defining in which states the action is available. As can be seen, a cowboy can always wait, but only shoot if they and their target are alive. Lastly, we declare three instances of the cowboy template on lines 20-22. We define the right and left opponent in the relabelling function after the name of the template. Any identifier in a template can be relabelled to another expression as long as the result is syntactically and semantically correct. The ATL formula ⟪billy⟫□billy.alive is satisfied if the cowboy billy has a strategy to stay alive. We can now run CGAAL with the following command: ./cgaal solver -m standoff.lcgs -f billy-can-stay-alive.atl, and CGAAL will tell us that the property is not satisfied. Billy has no strategy that can guarantee his survival. [2] Graphviz: https://graphviz.org/ This paper is available on Arxiv under CC 4.0 license. Arxiv

A Tool Overview of CGAAL: A Distributed On-The-Fly ATL Model Checker

This paper is available on arxiv under CC 4.0 license.
Authors:
(1) Falke B. Ø. Carlsen, Department of Computer Science, Aalborg University, Denmark & falkeboc@cs.aau.dk;
(2) Lars Bo P. Frydenskov, Department of Computer Science, Aalborg University, Denmark & larsbopark@gmail.com;
(3) Nicolaj Ø. Jensen, Department of Computer Science, Aalborg University, Denmark & noje@cs.aau.dk;
(4) Jener Rasmussen, jener@jener.dk;
(5) Mathias M. Sørensen, mathiasmehlsoerensen@gmail.com;
(6) Asger G. Weirsøe, asger@weircon.dk;
(7) Mathias C. Jensen, Department of Computer Science, Aalborg University, Denmark & mcje@cs.aau.dk;
(8) Kim G. Larsen, Department of Computer Science, Aalborg University, Denmark & kgl@cs.aau.dk. Table of Links Introduction Definitions Model Checking Tool Overview Evaluation Conclusion and References 2 Definitions We recall the definitions of concurrent games and alternating-time temporal logic. A computation starting in the state q is called a q-computation. Alternating-time Temporal Logic The alternating-time temporal logic (ATL) [1] is defined with respect to a finite set Π of propositions and a finite set Σ = {1,...,k} of players. An ATL formula is given by the abstract syntax: where p ∈ Π is a proposition and A ⊆ Σ is a set of players. The operators ⟪⋅⟫ and J⋅K are path quantifiers. We will refer to them as "enforce" and "despite", respectively. The ◯ ("next") and U ("until") are temporal operators. Additional temporal operators like ♢ ("eventually") and □ ("invariant") are derived as usual. Given a state q of a game structure S, we write q ⊧ φ to indicate that the state q satisfies the property described by φ. The satisfactory relation ⊧ is defined inductively: This paper is available on Arxiv under CC 4.0 license. This paper is available on arxiv under CC 4.0 license. Authors: (1) Falke B. Ø. Carlsen, Department of Computer Science, Aalborg University, Denmark & falkeboc@cs.aau.dk; (2) Lars Bo P. Frydenskov, Department of Computer Science, Aalborg University, Denmark & larsbopark@gmail.com; (3) Nicolaj Ø. Jensen, Department of Computer Science, Aalborg University, Denmark & noje@cs.aau.dk; (4) Jener Rasmussen, jener@jener.dk; (5) Mathias M. Sørensen, mathiasmehlsoerensen@gmail.com; (6) Asger G. Weirsøe, asger@weircon.dk; (7) Mathias C. Jensen, Department of Computer Science, Aalborg University, Denmark & mcje@cs.aau.dk; (8) Kim G. Larsen, Department of Computer Science, Aalborg University, Denmark & kgl@cs.aau.dk. This paper is available on arxiv under CC 4.0 license. Authors: Authors: (1) Falke B. Ø. Carlsen, Department of Computer Science, Aalborg University, Denmark & falkeboc@cs.aau.dk; (2) Lars Bo P. Frydenskov, Department of Computer Science, Aalborg University, Denmark & larsbopark@gmail.com; (3) Nicolaj Ø. Jensen, Department of Computer Science, Aalborg University, Denmark & noje@cs.aau.dk; (4) Jener Rasmussen, jener@jener.dk; (5) Mathias M. Sørensen, mathiasmehlsoerensen@gmail.com; (6) Asger G. Weirsøe, asger@weircon.dk; (7) Mathias C. Jensen, Department of Computer Science, Aalborg University, Denmark & mcje@cs.aau.dk; (8) Kim G. Larsen, Department of Computer Science, Aalborg University, Denmark & kgl@cs.aau.dk. Table of Links Introduction Introduction Definitions Definitions Model Checking Model Checking Tool Overview Tool Overview Evaluation Evaluation Conclusion and References Conclusion and References 2 Definitions We recall the definitions of concurrent games and alternating-time temporal logic. A computation starting in the state q is called a q -computation. q q Alternating-time Temporal Logic The alternating-time temporal logic (ATL) [1] is defined with respect to a finite set Π of propositions and a finite set Σ = {1,...,k} of players. An ATL formula is given by the abstract syntax: Alternating-time Temporal Logic where p ∈ Π is a proposition and A ⊆ Σ is a set of players. The operators ⟪⋅⟫ and J⋅K are path quantifiers. We will refer to them as "enforce" and "despite", respectively. The ◯ ("next") and U ("until") are temporal operators. Additional temporal operators like ♢ ("eventually") and □ ("invariant") are derived as usual. Given a state q of a game structure S, we write q ⊧ φ to indicate that the state q satisfies the property described by φ. The satisfactory relation ⊧ is defined inductively: q q q This paper is available on Arxiv under CC 4.0 license. Arxiv Arxiv

CHECKTUR

checktur.io

11-50 employees

Since 2022

COMPANY RANKING

CHECKTUR

EVERGREEN INDEX #2319

Representing this company? Click here to claim and customize this page!

Checktur WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!

CHECKTUR

checktur.io

11-50 employees

Since 2022

COMPANY RANKING

CHECKTUR

EVERGREEN INDEX #2319

RELATED COMPANIESRANK

STORIES ABOUT CHECKTUR

Representing this company? Click here to claim and customize this page!

Checktur WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!