Hey guys so I was fiddling around with an dapp Idea.
When I get a specific address from the smart contract,
it gives me a specific encoded type
for example 9HUG4x4wVzHmXRedwA6b9ygZbN/KGeDfmRDLgGZtLmI= .
How can I decode that to the the public address I want?
The answer https://stackoverflow.com/a/73395946/2945326 is a way to decode a base64 address into a 32-byte raw address/public key inside a smart contract.
In most cases, you should avoid decoding base64 within a smart contract. Instead, you should ensure that smart contracts always deal directly with raw bytes.
If you want to decode an address outside of a smart contract (for example to display it on a website), then you need to first decode the base64. This gives you a 32-byte raw address/public key.
To be displayed, this needs to be converted to an address following https://developer.algorand.org/docs/get-details/encoding/#address.
Concretely, in Python:
import base64
import algosdk
raw_address_bytes = base64.b64decode("ZXUc/psAtm6K6AOMpvytibbSa8H6WFc6O8XTp/rHuEE=")
address = algosdk.encoding.encode_address(raw_address_bytes)
print(address)
which displays
MV2RZ7U3AC3G5CXIAOGKN7FNRG3NE26B7JMFOOR3YXJ2P6WHXBA4IGKRJ4
See https://forum.algorand.org/t/how-to-convert-public-key-back-to-address-in-js-sdk/3643/3?u=fabrice
you can simple pass that encoded string to pyteal.Base64Decode()
this class would return an string that would be decoded public address.
Related
I am stuck trying to compile a contract using Remix. I am initializing an array as follows:
address[] public wmaticToUsdcPath =[0x0d500b1d8e8ef31e21c99d1db9a6444d3adf1270, 0x2791bca1f2de4661ed88a30c99a7a9449aa84174];
But Remix won't compile and is complaining that 0x0d500b1d8e8ef31e21c99d1db9a6444d3adf1270 is not an error. The exact error is, this looks like an array but has an invalid checksum. It is suggesting I prepend '00' to it and directing me to https://docs.soliditylang.org/en/develop/types.html#address-literals but I can't seem to understand what to do. Prepending '00' will change the address. I am working on the MATIC/Polygon network.
The funny thing is if I declare an address variable and assign the WMATIC address to it, it is accepted by the compiler.
Does anyone know why the MATIC address is not accepted in an array.
It turns out I just need to follow the instruction in the error message. I prefix the address with '00' and it solved the issue. The issue was caused because WMATIC (and also USDC) have address format that will not pass checksum for later versions of solidity. By adding the '00' it will make it pass the checksum during compilation but the address will still be the same on deploying (I was worried adding this will change the address of the token). My final solution looked like this:
address[] public wmaticToUsdcPath =[address(0x000d500b1d8e8ef31e21c99d1db9a6444d3adf1270), address(0x002791bca1f2de4661ed88a30c99a7a9449aa84174)];
You need to checksum the addresses.
Checksum of an address is basically adjusting capitalization of the letters (hex values a-f) based on values of the address hash. There are some tools to calculate the address checksum, for example this one. You can see the second half of this answer for more detailed explanation.
pragma solidity ^0.8;
contract MyContract {
address[] public wmaticToUsdcPath = [
0x0d500B1d8E8eF31E21C99d1Db9A6444d3ADf1270, // instead of 0x0d500b1d8e8ef31e21c99d1db9a6444d3adf1270
0x2791Bca1f2de4661ED88A30C99A7a9449Aa84174 // mind the capitalization of the letters
];
}
I send the following message with content type application/json:
However whene i get messages from the same RabbitMQ Web console, it shows the payload as String.
What am I doing wrong? Or am I fundamentally misunderstanding and the Payload is always of type String?
From the official docs:
AMQP messages also have a payload (the data that they carry), which AMQP brokers treat as an opaque byte array. The broker will not inspect or modify the payload. It is possible for messages to contain only attributes and no payload. It is common to use serialisation formats like JSON, Thrift, Protocol Buffers and MessagePack to serialize structured data in order to publish it as the message payload. AMQP peers typically use the "content-type" and "content-encoding" fields to communicate this information, but this is by convention only.
So basically, RabbitMQ has no knowledge on JSON, messages all are just byte arrays to it
From NodeJS Context:
If we want to send JSON object as message, we may get the following error:
The first argument must be of type string or an instance of Buffer,
ArrayBuffer, or Array or an Array-like Object. Received an instance of
Object
So, we can convert the JSON payload as string and parse it in the worker. We stringify the JSON object before sending the data the Queue-
let payloadAsString = JSON.stringify(payload);
And from worker's end, we can then JSON.parse
let payload = JSON.parse(msg.content.toString());
//then access the object as we normally do, i.e. :
let id = payload.id;
For anyone using .Net to send objects via RabbitMQ.
You have to serialise your JSON object to byte array, send via RabbitMQ then de-serialise after receiving. You can do this like this:
Install the Newtonsoft JSON library
using Newtonsoft.Json;
Create a model for your JSON object message (in this case AccountMessage)
Serialise your object into byte array like this:
byte[] messagebuffer = Encoding.Default.GetBytes(JsonConvert.SerializeObject(accountMessage) );
After receiving the message data, you can de-serialise like this:
AccountMessage receivedMessage = JsonConvert.DeserializeObject<AccountMessage>(Encoding.UTF8.GetString(body));
from here
Content Type and Encoding
The content (MIME media) type and content encoding fields allow publishers communicate how message payload should be deserialized and decoded by consumers.
RabbitMQ does not validate or use these fields, it exists for applications and plugins to use and interpret.
by the way, using the rabbitMQ web gui, you use the words content_type, however in code (javascript confirmed), you use the key name contentType. it's a subtle difference, but enough to drive you crazy.
I am currently sending data between my PC and an ARM M4 Microcontroller via UART. I've defined my own protocol where each message looks like this:
[START_CHAR LEN TYPE SEQ DATA CRC]
The START_CHAR and LEN fields help me determine when the data ends, after which I look up the TYPE (constant offset of 3) to figure out what data came in order to unpack it into a message class.
Now I'm looking into flatbuffers and it seems perfect except that I cannot encode the TYPE into the message without including it inside the actual message. Here is what I am trying to do:
namespace FlatMessage;
uint8 const TYPE = 50; // does not compile
table String {
value:string;
}
root_type String;
I could create an Enum but that is messy. Thank you!
[EDIT] I should add that I could just change the protocol to have an END_CHAR but I need to support the TYPE field for legacy reasons.
Well actually, I suppose I would still need the type to figure out how to deserialize it as a flatbuffer.
e.g.
uint8_t *buf = builder.GetBufferPointer(); // I can do this with END_CHAR because I could get the buffer.
auto receive_string = GetString(buf); // But I wouldn't know what the type is. e.g. this could be GetCoolString(buf).
You have a couple of options to store a type with a FlatBuffer:
Prefix a buffer yourself with a type.
Use the file_identifier feature of FlatBuffers, to make it possible to identify the type of FlatBuffer.
Store the type in FlatBuffers itself, by using a union type. Make the root table have a single union field.
I can across a copy methods from charTermAttr from the org.apache.lucene.analysis.tokenattributes.CharTermAttribute library.
Can anyone explain what copyBuffer and buffer does for charTermAttr? The documentation isn't very clear. If you could provide an example that would be great too!
CharTermAttributeImpl keeps internally a char array and a length variable that represents the internal term.
The copyBuffer method writes over this array by using the char array provided with the respective offset and length params.
The buffer method returns the internal array that you can directly modify. Additionally, you can get the term representation as a string by calling the attribute's toString method
Have a look at the javadocs for more details: http://lucene.apache.org/core/4_9_0/core/org/apache/lucene/analysis/tokenattributes/CharTermAttribute.html
I'm trying to get a signature -- either an NSMethodSignature object or at least the type encoding string -- for a method declared in a protocol.
Asking the Protocol object itself isn't possible, since a) it doesn't implement methodSignatureForSelector:, and b) (as noted by Kevin below) it's deprecated.
The runtime function protocol_getMethodDescription returns a struct objc_method_description, which isn't described anywhere in the docs. It's in a public header, though -- <objc/runtime.h>:
struct objc_method_description {
SEL name;
char *types;
};
It seems reasonable to assume that the types string in there is going to be the same kind of signature encoding string used elsewhere, such as that expected by +[NSMethodSignature signatureWithObjCTypes:], and indeed, it looks correct.
What I can't track down is an actual, verifiable connection between that string and the type encoding process.
I can't think what else it would be, but still, do I have any justification for relying on this types string to be valid for interaction with other objects/functions on the same runtime? Note that I'm not writing encoding strings myself or expecting them to have a given format or value -- I only want to pass them from one part of the runtime/framework to another, i.e., retrieve an encoding string from a protocol and a) use it to generate an NSMethodSignature object if one isn't otherwise available, and possibly b) compare it to that of a runtime-generated NSInvocation (i.e., in -forwardInvocation:).
Using Protocol as an object is deprecated. If you check the header <objc/Protocol.h> you'll see that pretty much everything on it is either not available in OBJC-2 or is deprecated as of OS X 10.5. What you can do is use protocol_getMethodDescription(), as you suggested, and pull out the types field. I'm not sure if it's actually officially documented that this is the type encoding of the method, but that is indeed what it is.