I know that AAD application ID is unique in one directory (tenant). It is a guid and apparently should be unique in whole world but collisions may be. The question is: does Azure while generation AAD application ID validate whether it is unique across all others directories or not?
If you look at the official document for application property you would know application id is
The unique identifier for the application that is assigned to an
application by Azure AD. Not nullable. Read-only
How Azure Application Id Generated Uniquely:
Application Id (GUID) break down like this:
60 bits of timestamp,
48 bits of computer identifier,
14 bits of uniquifier, and
six bits are fixed
Total of 128 bits.
The goal of this algorithm is to use the combination of time and location (“space-time coordinates” for the relativity geeks out there) as the uniqueness key.
However, there’s a possibility that, for example, two GUIDs are generated in rapid succession from the same machine, so close to each other in time that the timestamp would be the same. That’s where the uniquifier comes in.
When time appears to have stood still (if two requests for a GUID are made in rapid succession) or gone backward (if the system clock is set to a new time earlier than what it was), the uniquifier is incremented so that GUIDs generated from the “second time it was five o’clock” don’t collide with those generated “the first time it was five o’clock”.
Once you see how it all works, it’s clear that you can’t just throw away part of the GUID since all the parts (well, except for the fixed parts) work together to establish the uniqueness. This is how all that works.
Note: Even sometimes network address also considered for GUID.
Related
I am reading bep 5 and trying to understand how a token value is generated. As I understand the token value is a randomly generated value that is used in a get_peers query for safety. This same token value would then be used in an announced_peers query to see if the same IP previously requested the same Infohash.
My question is how is this value generated exactly? It says something about an unspecified implementation - does this mean I can implement it myself (for example by using the SHA-1 value)?
I tried looking at other beps but couldn't find anything about specific rules for generating a token value, found nothing.
The token represents a write permission so that the other node may follow up with an announce request carrying that write permission.
Since the write permission is specific to an individual node providing the token it is not necessary to specify how it keeps track of valid write permissions, as there needs to be no agreement between nodes how the implementation works. For everyone else the token is just an opaque sequence of bytes, essentially a key.
Possible implementations are
(stateful) keep a hashmap mapping from supplied tokens to their expiration time and which remote IP it is valid for.
(stateless) hash a secret the remote ip, remote id and a validity-time-window-counter. then truncate the hash. bump the counter on a timer. when verifying check with the current and the previous counter.
Since a token is only valid for a few minutes and a node should also have a spam throttle it doesn't need to be high strength, just enough bits to make it impossible to brute-force. 6-8 bytes is generally enough for that purpose.
The underlying goal is to hand out a space-efficient, time-limited write permission to individual nodes in a way that other nodes can't forge.
I am working on a anchor / solana program that provides liquidity to a number of pools, including saber.so and invariant.app. During the swap, I need to calculate the TVL, to provision a token at a fair exchange rate.
My question is: what is the best way to calculate TVL onchain?
The following are some approaches that I have in mind, each one with its shortcomings:
(1) Calculate off-chain, and provide this as an oracle:
We could calculate the TVL off-chain, and then provide this TVL as an oracle. The shortcomings are: chainlink (an oracle provider) on solana does not seem to support custom data-feeds, as is the case with ethereum.
Further more this solution increases the centralization of the app, it would be nice to have it on-chain. also there could be oracle-attacks which drain the reserves of the protocol.
(2) Have a giant list of liquidity-positions:
Another approach would be to keep track of all liquidity-positions that we as a protocol have provided liquidity in. Although this is possible, I believe that this would (very quickly), reach solana's account limit.
In this case, we would have a huge "state-"account, which tracks the following variables per pool:
token1_mint: Pubkey
token2_mint: Pubkey
token1_amount: u64
token2_amount: u64
token1_to_currency_pyth_feed_address: Pubkey
token2_to_currency_pyth_feed_address: Pubkey
provider: u8
Given that we have 4 * 32 + 2 * 64 bytes + 8 bytes = 264 bytes, we can have around 20 pools that we can deposit at any given point in time (because of a 4KB account limit on solana)
The second option seems like the way to go, as the first one if off-chain and prone to oracle-attacks. However, the second option still seems a bit hacky, as I would have to include this data-structure anytime I intend to calculate the total TVL.
Is there any other design ideas that come to your mind or that you have seen, that would be appropriate?
I don't know much about the overall design of your program to provide you with a good solution. I also don't know what invariant is, maybe that breaks what I'm about to describe below.
I assume that you have some instruction in your program which cpi calls into Saber etc and opens a liquidity position. Assuming that that instruction creates an account on the chain with the following information:
pool_address,
token_1_mint_address
token_2_mint_address
amount_token_1
amount_token_2
...
One simple solution is to loop through all those accounts, and since you have the amount and mint of each token, you can calculate the value using something like the pyth price oracle. I wouldn't do this on chain though since it can become pretty expensive fast! Perhaps is best to do it on the client side and write this information back to the chain.
The recent solana bootcamp videos actually have a tutorial on bringing off chain info back to the chain! https://www.youtube.com/watch?v=GwhRWde3Ckw&t=385s
Below is a demo of the runtime limitations of on chain programs, perhaps you could do the loop through the pool accounts, if you use some indexing and PDA to find the account address and assuming that you have a limited number of liquidity positions! However I wouldn't hardcode all the information into a single account, seems like an unsustainable approach that might cause a lot of issues down the line. Might give you superior performance however, not sure.
https://www.youtube.com/watch?v=5IrfSecDPeA&t=1191s
Anyways GL!
I have an Azure Functions app whose name is longer than 32 characters. This app has a production slot and a staging slot. Their default host ids will hence cause collisions, as explained in HostID Truncation can cause collisions.
I hence would like to set AzureFunctionsWebHost:hostId (or AzureFunctionsWebHost__hostId) with a unique value on my two slots to avoid this collision. Should this configuration value be slot-sticky or not?
As mentioned in Azure-function-host documentation we can explicitly specify host id's for your app settings as below:
AzureFunctionsWebHost__hostId (Windows and Linux)
AzureFunctionsWebHost:hostId (Windows only)
If there are any other restrictions that can be satisfied from the HostIdValidator
From Doc: An easy way to generate an ID would be to take a GUID, remove the dashes and make it lower case, e.g. 1835D7B5-5C98-4790-815D-072CC94C6F71 => 1835d7b55c984790815d072cc94c6f71
Most of the information was covered from the GIT discussion which you've shared.
HostID Truncation can cause collisions GitHub#2015
The host ID value should be unique for all apps/slots you're running
Actually this is true only when they share the same storage account. From my understanding, it means that when you use the same storage across all slots of your function for an app name with more than 32 characters (with an identical value for those 32 leading char), you must define a slot-stiky hostId.
These are a few Time To mechanisms that can have some light shun upon them as they can be quite useful to a developer. I will be answering them below in an attempt to explain what they can be used for and why on the #platform.
Time To Mechanisms (Attributes of Metadata)
Any data that is shared between #signs can go through several mechanisms. Some of these mechanisms include TTR (Time To Refresh), TTL (Time To Live), and TTB (Time To Birth).
Time To Refresh
TTR, which is an attribute of the metadata of a shared key, accepts an integer value which represents seconds. The subsequent refresh happens based on the given value: for example, if the set TTR value is 86400, then the refresh happens once in a day (there are 86,400 seconds in a day). Another very important attribute of the metadata is CCD (Cascade Delete), which is a boolean variable (a variable that accepts true or false values). For those who are well versed in SQL and database management, you will already have some understanding of what CCD does and how it functions.
If the CCD value is set as true when the sender deletes their original key, the cached key gets deleted on both the sender’s server and the recipient’s server. Correspondingly, if the CCD value is false when the sender deletes their original key, the cached key gets deleted on only the sender’s server and remains cached on the recipient’s server. But why is this useful? CCD is used to avoid unnecessary network calls. As an example: if #alice is in need of #bob’s phone number, she does not need to make a request from her server to #bob’s server to find it, but rather needs only to search locally on her device to find the phone number.
Let’s consider a similar example: #alice shares her phone number with her friends #bob and #john. A few months later, however, #alice purchases a new phone plan, resulting in a new phone number. If #alice has her #sign’s TTR variable set to true, once she updates her old phone number to match her new one, this updated value will also be reflected on #bob and #john’s devices. #alice also has the ability to set a specific time, in seconds, for when the new phone number will be cascaded on shared servers (this is TTB, which is described later). This can be 10 minutes, a day, or whatever specific amount of time she defines.
This function can be quite handy, especially if someone is constantly updating values on their server. This prevents a high density of calls and requests whenever someone wishes to see what new values exist on a shared server.
Time To Live
TTL (Time To Live) is quite self-explanatory: it defines how long data will live on a server. Anyone with an #sign has the ability to upload information on their server and define how long it stays on the server before it is automatically deleted. If #alice wishes to share her summer vacation getaway location as her current location, she has the option to share that summer vacation location for as long as she plans on being there!
To really take advantage of a mechanism like this, developers can combine it with other Time To commands to make life for themselves and those they share their information with easier. Say for instance Alice lives in sunny San Francisco, and owns a vacation home in Spain. With mechanisms such as Time To Refresh and Time To Live, Alice has the ability of travelling to her vacation home for several weeks, uploading her current location as Spain, and setting that information to live on her server for the several weeks that she will be staying at that location.
Time To Birth
Another Time To mechanism that is utilized within the #protocol is the Time To Birth mechanism. This mechanism allows individuals to upload information to their secondary server and have it become activated after a specified amount of time, in seconds. During the time that the data is not ‘active’, any recipients of this information will see the ‘null’ value in place until the activation has occurred.
For example, if #alice wishes to upload a web URL of her personal website after she has completed it, she can simply specify that the URL value can be uploaded to her secondary in exactly 1 days’ time. Until the value is updated a day later, #bob can only see that her website URL is ‘null’.
While executing the below mentioned powershell script, I will get the unique ID of the Azure Virtual Machine. I have a doubt with that. Even when I execute this script in the physical machine, I get an ID. I want to know,
what that ID exactly represents?
Is this ID unique for every machine?
Powershell Script:
$computerSystemProduct = Get-WmiObject -class
Win32_ComputerSystemProduct -namespace root\CIMV2
'BIOS GUID: "{0}"' -f $computerSystemProduct.UUID
The ID represents the System Information as a GUID.
This GUID is unique - for every machine.
See for reference
https://learn.microsoft.com/en-us/windows/desktop/cimwin32prov/win32-computersystemproduct
It's unique for every machine, and you can check the details here:
(Universally Unique ID) A 128-bit unique number generated by various
algorithms to identify hardware or software. Because the number is so
large, for all intents and purposes no two UUIDs can be the same. The
reason for UUIDs is that they can be combined from disparate sources
into one database without fear of duplication.